AD-A072  395 


UNCLASSIFIED 


OPERATING  SYSTEMS  INC  WOODLAND  CA  F/6  o/2 

A KNOWLEDGE-BASED  AUTOMATED  MESSAGE  UNDERSTAND I N6  METHODOLOGY  F— ETC(U) 
JUN  79  G M SILVA.  D L DWIGGINS.  S G BUSBY  E30602-77-C-0144 

RADC-TR-79-133  NL 


A KNOWLEDGE- BASED  AUTOMATED  MESSAGE  UNDERSTANDING 
METHODOLOGY  FOR  AN  ADVANCED  INDICATIONS  SYSTEM 


> ! 


in 

o 

co 

<N* 

o 


RADC-TR-79-1 33 

Final  Tachnical  Raport 
June  1979 


r* 


A KNOWLEDGE-BASED  AUTOMATED 
MESSAGE  UNDERSTANDING  METHODOLOGY 
FOR  AN  ADVANCED  INDICATIONS  SYSTEM 


Operating  Systems,  Inc. 

G.M.T.  Silva 
D.L.  Dwiggins 
S.G.  Busby 
J.L.  Kuhns 


LEVEL 


APPROVED  FOR  PUBLIC  RELEASE;  DISTRIBUTION  UNUMITED  I 


ROME  AIR  DEVELOPMENT  CENTER 

Air  Force  Systems  Command 

Griff iss  Air  Force  Base,  New  York  13441 


79  08  06  014 


This  report  has  been  reviewed  by  the  RADC  Information  Office  (01) 
and  is  releasable  to  the  National  Technical  Information  Service  (NTIS). 
At  NTIS  it  will  be  releasable  to  the  general  public,  including  foreign 
nations. 

RADC- TR- 79-133  has  been  reviewed  and  is  approved  for  publication. 


APPROVED: 


ANDREW  S.  KOZAK 
Project  Engineer 


APPROVED: 


Qtvo 


HOWARD  DAVIS 
Technical  Director 

Intelligence  and  Reconnaissance  Division 


FOR  THE  COMMANDER: 


JOHN  P.  HUSS 

Acting  Chief,  Plans  Office 


If  your  address  has  changed  or  if  you  wish  to  be  removed  from  the  RADC 
mailing  list,  or  if  the  addressee  is  no  longer  employed  by  your  organiza- 
tion, please  notify  RADC  (IRDE)  Griffiss  AFB  NY  13441.  This  will  assist 
us  in  maintaining  a current  mailing  list. 

Do  not  return  this  copy.  Retain  or  destroy. 


UNCLASSIFIED 

UCU«I  T > l «'.Mih  >'»  t'lisMt.l  »h*n  '.'mtm  t ’ 


\)  REPORT  DOCUMENTATION  PAGE  I t i k k or *om p r f t in* gj^o km 

T;  GOV  1 A v i r SSION  NoT^A**- nt  ClPil  NT’S  CATALOG  NUMHF  H 

t-  79-1 33  \ j /TcJj 


'RADClTR- 79-133 


£ KNOWLEDGE-JiASED  AUTOMATED .MESSAGE  UNDERSTANDING  Final Technical /etfml . \ 
METHODOLOGY  FOR  AN JDVANCED ^INDICATIONS  SYSTEM  . U 1?  Jut  77  — 17  Dan  79  | 


G.M.T. /Silva  \ J.Ly  Kuhns 
D.L.  Dwiggins  ; 

S.G.,  Busby 

■#  rr  R»  ORM'NG  ORGANI  AT. ON  N»MI  ANP  APPWI  SS 

Operating  Systems.  Inc. 

21031  Ventura  Boulevard 
Woodland  Hills  CA  91364 

U CONTROL  t INI.  O*  Ml  I SAM'  AS  A Ml  'A 

Rome  Air  Development  Center  ( IRDt ) 
Griffiss  AFB  NY  13441 


M CONTftACI  OR  GRAN  t WUMlCWn 


I / ! F 7-0^14 4] 


1C  PR,<  .HAM  TlfMEN’  PROJh  T T ASK 
AMI  A A AORK  I'NlT  N w M M L U* 

-627021  / . 4 


j£>  I 45941238 


I J ^ 


Cat 


79 


i.  rs*-  PLl' 

193 


TT’  MONI  TORlN  G AGt  N ' N AMI  A APPMI  S'-  .1  .Oftr-rf  lr  ■ 1 ■■■•'  < W/. . «•  ' ] IS  SI  jRlTV  CLASS  'I'Stfri  ' 


l/TT.  !(1ICLASS1F1LD 

./  *”  I Mst  Pf  . , A SSI  f 1 1 A * N POUNuRAC.N 

— A. rh/AVM,°"° 


[I  A niSTniPnTiON  ST  ATEMf  N’  1 f.S  1 « N >r  r 


Approved  for  public  release;  distribution  unlimited. 


[l*  DlSTRiRpTlON  ST  AlfMI  NT  .>1  th*  f irt  Ml-’  A ' 1 1 .1- . fe  • * f.  • Kef  • 


IS  SuFfLlMI  N'  ARi  NOTES 

RADC  Project  Engineer;  Andrew  S.  Kozak  (1RDE) 


'A  Mv  * 'IDS  . '•in. 


Intelligence  Data  Processing  Logic  Programming 

Data  Base  Generation 

Natural  Language  Processing 

Artificial  Intelligence 

Computational  Inguistics 

ARSTRAi.  ’ • * n 

his  report  describes  an  RADC  sponsored  effort  related  to  the  development  of 
a technology  based  upon  a computer  'understanding"  of  natural  language,  with 
the  aim  of  deriving  fixed-format  problem-oriented  information  records  from 
the  narrative  text  of  intelligence  messages  in  support  of  1SW  functions. 

The  introductory  section  provides  an  overview  of  the  concepts  that  serve  as  a 
foundation  for  the  RADC  developmental  program  for  both  interactive  and  auto- 
mated exploitation  of  the  content  of  intelligence  messages,  summarizes  the 
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work  performed  under  the  current  effort,  and  presents  our  general  conclusions.^ 

Section  2 describes  some  of  the  fundamental  concepts  underlying  message  text 
analysis.  It  discusses  the  structure  of  event  reports  as  viewed  from  four 
different  perspectives;  develops  the  concept  of  an  "event",  which  emerges  as 
the  logical  unit  of  analysis  and  becomes  the  basis  for  describing  intelligence 
information;  and  presents  the  "template"  as  an  event-centered  information 
structure. 

Section  3 describes  the  design  and  Implementation  of  the  Event  Representation 
Language  (ERL),  which  is  centered  around  the  notion  of  "template"  and  embodies 
both  the  declarative  and  procedural  knowledge  requisite  for  the  complete 
representation  of  events  and  their  properties.  ERL  is  embedded  in  the  program- 
ming language  Prolog,  an  interactive  programming  language  based  upon  a simple 
proof  procedure  involving  a subset  of  classical  logic.  The  method  of  encoding 
templates  in  Prolog  is  discussed  in  detail.  This  is  followed  by  an  explanation 
of  the  ERL  procedures  developed  for  Event  Record  Synthesis,  and  a detailed 
example  of  how  ERL  template  representations  accomplish  the  semantic  interpre- 
tation process,  that  maps  the  syntactic  structures  output  by  the  parser  onto 
event  records. 

Section  4 comprises  an  overview  of  MATRES  II,  which  is  implemented  on  the 
PDP  11/45  under  RSX-11D.  The  base  language  for  all  the  programs  — except 
the  ERL  compiler  --  is  Forth.  The  ERL  Compiler  is  coded  in  SPITBOL,  a dialect 
of  SNOBAL  4,  which  was  chosen  because  of  its  excellent  facilities  for 
compiler  writing. 

Part  II  of  the  report  presents  a detailed  description  of  the  implementation  of 
MATRES  II.  Its  data  structures  and  algorithms  for  the  sentence  input  and 
grammar  processing  vocabulary  and  the  capabilities  in  the  area  of  morphology 
are  described.  The  implementation  of  the  ERL  evaluation  process,  including 
the  abstract  machine  which  is  the  target  language  of  ERL,  is  described  in 
Section  4.  The  ERL  Compiler,  which  is  the  only  non-Forth  module,  is  discussed 
in  Section  5. 

A supplementary  report  not  for  publication  is  on  file. 
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EVALUATION 


The  main  objective  of  the  work  described  in  this  report  was  to  develop  a 
computer-based  technology  which  would  substantially  assist  the  I&W 
analyst  in  reviewing  and  processing  the  contents  of  large  volumes  of 
message  traffic. 


In  particular,  this  effort  focuses  on  providing  a detailed  conceptual 


and  methodological  framework  for  an  advanced  event  processing  system 
designed  with  the  aim  of  distilling  significant  information  elements 
from  the  narrative  text  of  intelligence  messages  and  synthesizing  fixed- 
format,  problem-oriented  information  structures  in  support  of  I&W  data 
base  generation  and  update  functions.  These  information  structures 
present  information  to  the  analyst  in  a compact  and  usable  format  thus 
reducing  his  burden  and  making  it  easier  for  him  to  concentrate  on 
higher-level  analytical  activities.  Specifically,  the  work  described 
addresses  the  issues  involved  in  synthesizing  meaning  representations 
from  a particular  class  of  intelligence  messages  constituting  reports 
related  to  the  air  activities  domain,  used  by  the  advanced  Indicator 
System  (AIS)  at  the  NMIC. 


The  task  of  teaching  a computer  to  "understand"  language  and  identify 
relevant  information  elements  is  not  a trivial  one.  It  requires  the 
utilization  of  advanced  technologies  involving  formal  syntactic  and 
semantic  analyses  of  the  sentences  of  a text,  and  the  development  of 
techniques  for  synthesizing  appropriate  meaning  representations  in  the 
form  of  machine-processable  information  records. 

vi 


A system  — designated  as  a Message  Analyzer  Testbed  and  Results  Evaluation 
System  (MATRES)  — is  presented  ' ■ the  form  of  three  major  components: 

(1)  The  Lexical  Unit  Recognizer,  (2)  The  Augmented  Transition  Network 
Parser,  and  (3)  The  Event  Representation  Language  Machine.  Taken 
together,  these  components  analyze  incoming  textual  reports  of  events 
and,  from  them,  synthesize  "event  records"  (i.e.,  extract  relevant 
information  and  store  it  in  event-centered  information  structures  utili- 
zable  as  data  base  records).  The  technique  employs  frame-like  "event 
templates"  for  representing  general  knowledge  about  event  classes. 

These  are  essentially  intensional  descriptions  of  events  and,  as  embedded 
in  the  system,  they  behave  as  active  data  structures  which  drive  the 
synthesis  process.  The  system,  as  currently  conceived,  provides  an 
adequate  conceptual  basis  for  a generalized  text  "understanding"  system 
capable  of  dealing  with  intelligence  reports  describing  events  involving 
movements  and  activities  of  objects  comparable  to  aircraft  (i.e.,  missiles, 
satellites,  ships,  submarines,  etc.). 


One  of  the  notable  features  of  the  system  is  the  use  of  the  programming 
language  Prolog,  a formalism  based  upon  a subset  of  classical  logic, 
which  lends  itself  particularly  well  to  the  encoding  of  the  logical 
argument  structure  of  event  descriptions.  Recent  investigations  reported 
in  the  literature  show  that  Prolog  is  not  only  used  for  the  grammatical 
description  of  structures  and  processes  of  natural  language,  but  can  also 
be  used  as  a practical  tool  and  a unifying  principal  for  the  description 
and  manipulation  of  data  bases.  The  use  of  Prolog,  therefore,  deserves  at- 


tention in  any  further  investigation  related  to  automated  data  base  generation. 


A 


In  conclusion,  the  approach  taken  in  this  investigation  is  a significant 
step  in  providing  a framework  for  a system  whose  main  purpose  is  to  map 
narrative  text  into  information  on  structures  in  support  of  I&W  functions. 

ANDREW  S.  KOZAK  ' 

Project  Engineer 


1.0  Introduction  and  Summary 

1.1  Introduction 
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This  report  describes  an  RADC  sponsored  contractual  effort  related  to  the  devolopme.it 
of  automated  analytical  tools  in  support  of  the  l&W  analyst. 

The  task  of  an  intelligence  analyst  is  to  predict  the  future  on  the  basis  of  information  * 

describing  what  has  happened  in  the  past  and  what  events  are  currently  taking  place. 

The  basic  information  source  for  most  analysts  is  intelligence  messages,  which  come  in 
large  volumes  from  many  different  originators,  largely  in  the  form  of  narrative  tc  xt. 

The  questions  the  analyst  asks  himself  are:  "What  is  happening?"  "What  does  it  mean  in 
terms  of  my  knowledge  about  similar  events  in  the  past?",  "What  is  going  to  happen 
next?"  He  is  concerned  with  certain  states  of  affairs,  and  events  signifying  changes  in 
these  states  of  affairs.  His  evaluations  of  incoming  information  are  based  on  his  cogni- 
tive models  of  such  states  of  affairs,  the  personalities,  entities,  and  processes  involved, 
and  the  potentialities  and  constraints  associated  with  changes  in  an  existing  state  of 
affairs. 

Given  the  volume  of  information  he  must  sift,  and  the  complexity  of  the  cognitive  models 
Involved,  the  difficulties  of  the  analyst’s  task  are  obvious.  Aids  to  support  his  analytical 
processes  clearly  must  involve  means  for  distilling  the  content  of  incoming  information 
Into  a form  which  is  compact,  usable,  and  compatible  with  his  view  of  the  world. 

The  work  described  here  Is  concerned  mainly  with  the  development  of  a technology  for 
the  automated  analysis  of  unformatted  (free-text)  with  the  a,m  of  transforming  it  into 
fixed-format,  problem-orienied  records,  reflecting  its  information  content.  The  subject 
domain  under  investlgaton  Is  that  of  air  activities. 

When  reviewing  narrative  text,  the  human  analyst  uses  his  innate  knowledge  of  English 
grammar,  as  well  as  his  extra-linguistic  knowledge  of  entities  such  as  aircraft,  time, 
location,  and  actions  — including  all  the  relevant  concepts  which  can  be  attributed  to  or 
are  implied  by  such  entities  — and  extracts  those  information  items  which  are  relevant 
to  his  task. 

In  order  to  model  this  human  cognitive  activity,  the  computer  must  be  equipped  with 
representations  of  both  linguistic  and  extra-linguistic  knowledge,  and  a means  of  mani- 
pulating such  representations  for  the  analysis  of  text  and  synthesis  of  information  ele- 
ments. The  elements  must  then  be  presented  in  a clear  and  useful  format  suitable  for 
the  task  at  hand. 

The  approach  adopted  by  OSI  is  based  upon  current  advances  in  language  "understand- 
ing" by  computer,  as  exemplified  by  work  in  Computational  Linguistics,  Artificial  Intelli- 
gence, Cognitive  Psychology,  and  non-numeric  programming  technology.  A survey  of  the 
field  as  related  to  the  work  reported  here  can  be  found  in  Silva  and  Montgomery  (1978). 

Briefly,  OSI’s  approach  to  the  problem  combines  a "bottom-up"  data-driven  analysis 
based  upon  linguistic  and  logical  principles  with  a "top-down"  conceptually  driven 
domain-specific  interpretation  of  the  structures  generated  by  the  input  analysis.  The 
"bottom-up"  analysis  is  carried  out  by  an  augmented  transition  network  (ATN)  parser, 
which  uses  a dictionary  and  a grammar  of  the  reporting  language  to  produce  a perse 
tree  showing  the  constituent  structures  of  the  input  string  and  their  hierarchical  rela- 
tionships. The  interpretive  procedures  are  embedded  in  the  Event  Representation 
Language  (CR1  ),  which  uses  domain-specific  knowledge  stored  in  permanent  data 


structures  called  "templates"  to  transform  the  linguistic  structures  generated  by  the 
parser  Into  template-derived  content  representations. 

1.2  Summary 

This  final  report  presents  the  results  of  the  exploratory  and  developmental  work  per- 
formed under  this  contract.  Briefly,  the  work  involved  extensions  and  additions  to  the 
simple  ATN  grammar  constructed  under  a previous  contract  to  accept  a wider  range  of 
linguistic  structures;  the  refinement  of  the  notion  of  "template"  as  a data  structure  for 
the  representation  of  knowledge  about  events;  the  design  and  implementation  of  the 
Event  Representation  Language,  a language  written  to  explore  the  use  of  the  “template" 
as  a knowledge  representation  technique  with  which  to  build  systems  for  automated 
language  analysis;  and  finally,  the  construction  and  implementation  of  algorithms  for  the 
automated  analysis  of  narrative  text  and  Its  subsequent  transformation  into  formal  con- 
tent representations. 

A major  effort  was  devoted  to  the  implementation  of  MATRES  II,  the  OSI  message  text 
analysis  system,  which  incorporates  the  technologies  mentioned  above,  and  involves  the 
ability  to  digest  narrative  text  and  systematically  transform  It  into  concise,  machine 
processable  content  representations,  called  ’event  records’,  in  which  a message  can  be 
viewed  from  several  perspectives:  time,  location,  organization  involved,  activity  type, 
etc. 

Table  1-1  shows  an  input  sentence  and  the  corresponding  event  record  produced  by 
MATRES  II. 

The  report  is  divided  Into  two  major  parts.  Part  I deals  with  system  design,  while  Part  II 
describes  the  implementation  of  MATRES  II. 

Section  2 of  Part  I describes  some  of  the  fundamental  concepts  underlying  message 
text  analysis.  Section  2.1  describes  the  structure  of  event  reports  viewed  from  dif- 
ferent perspectives.  Four  levels  of  description  are  distinguished,  each  corresponding  to 
a major  processing  phase. 

In  Section  2.2,  the  ’event’  emerges  as  the  logical  unit  of  analysis  and  becomes  the 
basis  for  describing  Intelligence  information.  Events  have  a complex  Internal  structure 
and  raise  special  representational  issues.  OSI  has  given  particular  consideration  to  this 
question  and  has  developed  an  event-centered  Information  structure  called  a "tem- 
plate", which  lends  itself  particularly  well  to  the  description  of  events  and  their  associ- 
ated concepts.  In  Section  2.3,  the  template  Is  first  described  from  the  point  of  view  of 
the  user,  stressing  those  properties  which  render  it  particularly  useful  as  an  analytical 
aid.  This  is  followed  by  a description  of  the  internal  structure  of  the  template. 

Section  3 describes  the  design  and  implementation  of  the  Event  Representation 
Language,  which  is  centered  around  the  notion  of  "template"  and  embodies  both  the 
Declarative  and  procedural  knowledge  requisite  for  the  complete  representation  of 
events  and  their  properties.  It  has  the  additional  advantage  of  being  readily  processable 
by  computer. 

ERL  Is  embedded  in  the  programming  language  Prolog,  an  Interactive  programming 
language  based  upon  a simple  proof  procedure  involving  a subset  of  classical  logic.  We 
were  fortunate  to  discover  this  language  at  a time  when  we  were  searching  for  a qood 
representation  for  the  template  concepts  that  we  were  developing  in  an  intuitive  and 
Informal  way.  Prolog  gave  us  not  only  a natural  and  perspicuous  notation  for  the  uniform 
representation  of  the  template  concepts,  but  also  provided  a feasible  and  fairly  efficient 
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Table  1-1  Example  Input  and  Output  by  MATRES  II 


♦ 


I nput 


I TWO  UGANDAN  AIRCRAFT  FROM  REGIMENT  A1313  AT  ENTEBBE  I 
I DEPLOYED  TO  GULU  AT  0200Z  ON  21  FEBRUARY.  I 
♦ + 


I Output  I 

I I 

Event:  DEPLOY  I 

. Object:  . 

. . . Equlpment=  UGANDAN  ACFT  ( 

. . . National ity=  UGANDAN  , 

. . . Subordination=  FROM  REGIMENT  A3  13 

... Stagingbase*  AT  ENTEBBE  I 

. . . Number=  TWO  1 

Destinations  TO  GULU 

Times  AT  0200Z  ( 

Date=  ON  21  FEBRUARY 
EVENT  RECORD  COMPLETE. 



Implementation  approach. 

Section  3.2  illustrates  the  method  of  encoding  templates  in  Prolog.  This  is  followed  by 
an  explanation  of  the  ERt  procedures  developed  for  F-vont  Record  Synthesis  (3.3),  nnd  a 
detailed  example  of  how  ERL  template  representations  accomplish  the  semantic 
Interpretation  process,  which  maps  the  syntactic  structures  output  by  the  parser  onto 
event  records  (3. 'I). 

Section  4 comprises  a brief  overview  of  MATRES  II,  a description  of  the  scope  of  the 
linguistic  grammar  and  lexicon  developed  for  the  aircraft  domain,  a description  of  thu 
MATRES  II  parser,  and  a discussion  of  some  fundamental  issues  underlying  the  selection 
of  template  descriptors  tor  a particular  subject  domain.  It  concludes  with  the  list  of  the 
descriptors  so  far  identified  for  the  air  activities  domain. 

MATRES  II  is  Implemented  on  the  PDP  11/46  under  RSX-11D.  Ihe  base  language  for  all 
the  programs  --  except  the  ERL  compiler  — is  forth.  The  T RL  compiler  is  coded  in  SPIT  - 
BOt , a dialect  of  SNOROl  4,  which  was  chosen  because  of  its  excellent  facilities  for 

compiler  writing. 

Part  II  of  the  report  presents  a description  of  the  implementation  of  MATIUS  II.  Section 
2 of  Part  II  describes  the  data  structures  and  algorithms  tor  the  sentence  input  and 
grammar  processing  vocabulary;  this  vocabulary  is  essentially  an  extensive  modification 
of  the  MATRES  I system.  Section  3 describes  the  capabilities  added  In  the  area  of  mor- 
phology. The  implementation  of  the  ERL  evaluation  process,  including  the  abstract 


machine  which  Is  the  target  language  of  ERL.  Is  described  in  Section  4.  The  ERL  com- 
piler, which  Is  the  only  non-Eorth  inoduie,  Is  discussed  In  Section  6.  The  last  three  sub- 
sections are  intended  as  a guide  to  the  Forth  program  files  listed  in  Appendix  A,  and  pro- 
vide glossaries  of  the  Words  In  those  files. 

Appendices  A-G  contain  program  listings  of  all  the  MATRES  II  modules  (A),  an  Introduction 
to  the  programming  language  Prolog  (B).  a listing  of  the  aircraft  domain  lexicon  (C),  a list- 
ing of  the  current  version  of  the  ATN  grammar  (0),  a sample  listing  of  sentences  now 
parsed  by  the  MATRES  II  System  (E),  a set  of  examples  of  system  Input/output  (F),  and 
operating  instructions  for  MATRES  II  at  OSI(G). 

1.3  Conclusions 

The  method  of  approach  which  OSI  has  adopted  since  the  inception  of  the  RADC  Explora- 
tory and  Developmental  program  for  Automated  Data  Base  Generation  has  been  to  look 
ahead  to  the  potential  capabilities  of  a future  system  for  both  interactive  and  fully 
automated  exploitation  of  the  narrative  text  of  intelligence  messages,  and  to  develop  a 
methodology  that  will  remain  valid  for  applications  of  considerably  greater  scope  than 
the  one  currently  under  development. 

Although  MATRES  II  is  at  an  early  stage  of  development,  it  has  demonstrated  that  OSI's 
Initial  design  concept  was  sound,  and  can  eventually  be  developed  into  a useful  opera- 
tional tool  in  support  of  l&W  functions.  The  concepts  underlying  Its  design  and  imple- 
mentations appear  so  useful,  that  the  system  has  already  aroused  considerable  interest 
both  within  and  outside  the  intelligence  community. 

One  of  the  noteworthy  features  of  MATRES  II  is  its  modular  design,  which  has  greatly 
facilitated  its  implementation.  In  spite  of  its  complexity,  MATRES  II  was  written  by  a sin- 
gle programmer  working  only  half-time  in  about  one  year. 

There  are  two  aspects  of  MATRES  II  as  a language  "understanding"  system  that  make  It 
somewhat  unusual,  and  thus  deserve  particular  mention.-  first,  It  operates  on  a 16-bit 
minicomputer,  within  a quite  limited  amount  of  available  memory  (64K  bytes);  second,  It  is 
written  not  in  one  of  the  popular  Al  extensions  to  LISP,  but  in  Forth,  a language  designed 
for  use  on  small  minicomputers  which  combines  a low-level,  machine-oriented  semantics 
with  a natural  facility  for  extension  of  the  semantics  in  a user-defined  way.  It  was 
basically  those  combined  properties  of  Forth,  together  with  Its  fairly  simple  "virtual 
memory"  facility,  that  has  made  it  possible  to  implement  such  a structurally  complex 
application  on  a small  machine  in  a relatively  short  time.  As  it  currently  exists,  the 
MATRES  II  system  fills  the  available  memory  with  only  a small  amount  of  dynamic  space 
available  for  sentence  processing;  this  can  be  ameliorated  with  a modest  amount  of 
work,  at  the  cost  of  noticeably  slowing  the  processing  due  to  virtual  memory  I/O. 
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2.0  Message  Text  Analysis:  Fundamental  Concepts 

In  this  section  we  explicate  some  fundamental  concepts  related  to  message  text 
analysis.  We  begin  by  a formal  description  of  event  reports,  which  constitute  the  primary 
data  of  our  analysis  programs.  Next,  we  consider  the  notion  of  ’event’,  which  emerges 
as  the  primary  unit  of  analysis,  and  becomes  the  basis  for  the  design  of  the  Event 
Representation  Language  described  in  detail  in  Section  3.  Finally,  we  present  the  con- 
cept of  a ’template’,  first  as  an  analytical  aid  designed  to  support  the  analyst  in  his 
task,  and  second,  as  an  information  structure  which  provides  an  event-centered  frame- 
work for  the  uniform  and  compact  description  of  event  data  contained  in  intelligence 
messages. 

2.1  The  Structure  of  Event  Reports 

Work  under  previous  contracts  has  shown  that  the  formal  description  of  event  reports 
requires  a multi-level  approach.  Four  levels  have  been  identified  to  date,  each  involving 
a different  aspect  of  event  reporting,  and  each  based  upon  different  considerations. 

2.1.1  The  Macro  Level.  This  level  of  description  involves  the  composition  of  reports  in 
terms  of  individual  messages  and  is  based  upon  operational  considerations. 

An  ’Event  Report’  is  defined  as  a collection  of  one  or  more  messages  transmitted  over  a 
period  of  time  and  dealing  with  the  same  event.  For  example,  an  event  report  concern- 
ing a specific  flight  might  consist  of  three  messages  Ml,  M2,  and  M3.  Ml  might  describe 
the  flight  of  some  as  yet  unidentified  aircraft  over  some  general  area.  A second  mes- 
sage M2  might  request  a change  of  any  one  of  the  flight  parameters  reported  in  Ml, 
while  a third  message  M3  might  be  a follow-up,  adding  new  information  to  the  aircraft 
first  reported  as  ’unidentified’. 

If  all  parameters  of  an  event  are  clear  to  the  observer  at  the  time  of  reporting,  and  can 
therefore  be  reported  with  certainty,  the  description  of  the  event  usually  involves  only 
one  message. 

From  the  point  of  view  of  automated  computer  analysis,  a distinction  must  he  made 
between  those  messages  that  contain  new  event  descriptions  (i.e.,  descriptions  of 
events  reported  for  the  first  time),  and  those  that  either  request  changes  in  the  param- 
eters of  some  previously  reported  event,  or  add  information  to  previously  underspecified 
parameters.  From  an  operational  point  of  view,  a first  report  involves  creating  a new 
data  element,  while  requests  for  change  and  updates  involve  changes  and/or  additions 
to  an  already  existing  structure. 

Let  us  call  the  class  of  messages  that  lead  to  the  creation  of  new  data  elements  class 
MO,  and  those  that  imply  changes  to  the  data  base  class  Ml.  The  composition  of  event 
reports  at  this  level  can  now  be  formalized  in  the  form  of  a grammar  using  BNF  notation: 

(1)  <Event  Report>  -*  <Message>|  <Messagel  ist> 

<Messagel ist>  -*  <Message>  I <Messagel  istxand><Message> 

<Message>  -»  MO,  Ml 

Work  under  this  contract  has  focussed  mainly  on  messages  of  class  MO,  i.e.,  reports  of 
new  events.  In  the  next  section  we  examine  the  structure  of  such  messages  from  the 
point  of  view  of  their  information  content. 

2.1.2  The  Message  Level.  This  level  of  description  involves  the  composition  of  single 
messages  In  terms  of  classes  of  events  characteristic  of  a particular  subject  domain.  In 
the  following  paragraphs  we  shall  be  concerned  only  with  messages  of  class  MO. 


i 

I 

|. 
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Messages  can  have  a complex  internal  structure  comprising  header  information,  followed 
by  either  formatted,  seml-formatted,  and/or  unformatted  (narrative)  text  portions, 
before  ending  with  some  special  symbols  signalling  the  conclusion  of  the  message. 

Since  this  work  is  concerned  mainly  with  the  narrative  text  portions  of  messages,  we 
shall  describe  the  messages  in  terms  of  three  components:  a ’pre-text’  component,  the 
’text’  component,  and  a ’post-text’  component. 

The  ’text’  component  of  a single  class  MO  message  may  contain  the  description  of  one 
or  more  new  events.  Of  course,  not  everything  reported  In  a message  text  Is  a descrip- 
tion of  an  event.  There  are  also  objects,  and  states,  and  processes,  and  perhaps  other 
entities.  However,  events  are  of  fundamental  Importance  and  it  Is  expedient  to  treat 
object,  state,  and  process  descriptions  as  special  types  of  events,  (for  a full  discussion 
of  the  concept  of  an  'event'  see  Section  2.2). 

Thus,  a message  may  state  that  a particular  set  of  aircraft  carried  out  a penetration 
flight  over  some  country,  and  then  engaged  in  some  other  activity  before  returning  to 
homebase.  Such  a message  describes  a chain  of  connected  events:  a penetration  flight, 
followed  by  an  activity,  followed  by  a return  to  homebase,  all  involving  the  same  set  of 
aircraft.  The  events  reported  on  in  a message  need  not  always  be  connected  as 
described  in  the  previous  example.  It  is  quite  possible  for  a message  to  report  on 
several  seemingly  unconnected  events. 

The  content  of  a message  can  now  be  formally  characterized  In  terms  of  the  ’event’  as 
the  primitive  unit: 

(2)  <Message>  -»  <Pre-text>  <Text>  <.Post-text> 

<Text>  -*  <Event>  ( <Eventltst> 

<Eventlist>  -*  <Event>  | <Eventlist>  <and>  <Event> 

<Event>  -»  el,  e2,  e3 en 

Note  that  <and>  is  a symbol  of  the  metalanguage  and  represents  a set  of  operations  and 
relations  on  events,  while  the  set  of  event  classes  characteristic  of  the  subject  domain 
covered  by  the  class  of  reports  'Event  Report'  defined  In  (1)  above  is  symbolized  by 
{el en}. 

We  shall  call  (2)  the  ’Message  Grammar’.  It  consists  of  a designated  non-terminal  <Mes- 
saye>,  called  the  ’initial’  symbol,  a set  of  non-terminal  symbols  Vn,  the  set  of  given  sym- 
bols Vt,  called  terminals,  and  the  four  productions  in  (2). 

Vn  = Message,  Pre-text,  Text,  Post-text,  Eventllst,  Event,  and 
Vt  = (el  ,e2,e3 en) 

The  set  {e1,e2 en}  comprises  the  ’primitives’  of  the  ’Message  Language’  described  in 

(2),  and  will  vary  from  subject  domain  to  subject  domain. 

2.1.3  The  Event  Level.  This  level  involves  the  description  of  events  in  terms  of  their 
properties,  including  time,  location,  action,  and  object(s)  involved  In  the  action. 

Event  descriptions  take  two  forms:  intensional  descriptions,  and  extensions I descrip- 
tions. 

An  Intensional  description  is  an  abstract  description  of  a class  of  individuals  in  terms  of 
a set  of  invariant  properties  common  to  all  members  of  the  class.  Thus  the  intensional 
description  of  the  class  of  flight  events  would  state  that  all  such  events  are  associated 
with  objects  that  can  fly,  have  a specific  location  at  some  point  in  time,  may  involve  a 
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mission,  and  can  further  be  specified  In  terms  of  path,  altitude,  direction,  and  extent  of 
flight.  It  would  also  state  any  associated  inferences,  such  as,  for  example,  that  a flight 
event  Is  necessarily  preceded  by  a take-off  event. 

An  extensions I description  Involves  one  Individual,  i.e.,  a unique  member  of  a class  of 
individuals  in  the  world  being  modeled.  A simple  example  Is  the  description  of  a specific 
aircraft  (e.g.,  a MiG-21)  flying  in  a given  direction  (e  g.,  north),  at  a particular  time  (e  g., 
0100Z). 


The  representational  construct  developed  for  the  description  of  events  is  the  'template'. 
It  is  an  abstract  data  structure  containing  a collection  of  Invariant  information  reflecting 
the  analyst’s  view  of  the  concept  It  describes.  All  information  represented  in  templates 
Is  associated  with  rules  governing  its  use. 

The  class  of  individuals  to  which  an  intensional  description  applies  is  called  the  ex  ten 
sion  of  the  general  concept  described  by  the  template.  In  the  context  of  Event 
Language  Recognition,  descriptions  of  individual  events  are  called  'Event  Records’.  Thus, 
the  set  of  event  records  describing  events  of  the  same  class,  i.e.,  event  records  related 
to  a particular  template,  constitute  the  extension  of  the  concept  described  by  the  tem- 
plate. 

Section  2.3  gives  a general  overview  of  the  template  from  the  the  viewpoint  of  the  user 
and  stresses  those  features  which  can  serve  as  an  aid  to  the  analyst.  This  is  followed 
by  a detailed  study  of  the  internal  structure  of  the  template  as  the  fundamental 
knowledge  structure  for  the  representation  of  event  data.  The  criteria  for  the  selection 
of  the  descriptors  appropriate  for  a particular  subject  domain,  and  the  methodology 
employed  as  applied  to  the  aircraft  domain  are  discussed  in  detail  in  Section  4.5. 

2.1.4  The  Linguistic  level.  This  brings  us  to  the  fourth  and  last  level  of  description  dis- 
cussed here,  namely  to  the  description  of  the  linguistic  structure  of  narrative  text.  In 
the  MATRES  II  System,  the  linguistic  structure  is  defined  by  means  of  an  augmented 
transition  network  grammar  in  terms  of  familiar  linguistic  categories  such  as  sentence, 
nounphrase,  verbgroup,  prepositional  phrase,  adverb,  and  others. 

In  order  to  expedite  processing,  a number  of  language  specific  categories,  not  usually 
found  in  traditional  grammars,  were  added.  Thus,  the  familiar  definition  of  prepositional 
phrase  In  (a)  was  augmented  to  encompass  dates  (b)  and  times  (c): 

(a)  pp  -*  prep  + nounphrase 

(b)  pp  -*  prep  4 date 

(c)  pp  -»  prep  4 time 

where  ’date’  and  ’time’  are  non-terminals  of  the  grammar  with  their  own  internal  struc- 
ture. The  MATRES  II  grammar  and  its  associated  lexicon  are  described  In  detail  in  sec- 
tion 4.3  of  this  report. 

2.2  The  Concept  of  an  Event* 

Although  the  event  concept  Is  fundamental  In  message  analysis,  no  standardised  termi- 
nology for  describing  or  classifying  events  exists.  Thus,  when  reference  is  made  to  the 
parameters  of  ’event/time/location,'  the  event  concept  used  is  that  of  a type  of 


* This  concept  was  originally  developed  in  Kuhns,  et  al.  (1975)  under  a previous  RADC 
contract. 
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activity.  In  another  usage  ’event’  refers  to  a fact.  The  event  concept  in  physics  is  that 
of  a point  in  the  spacetime  continuum,  and  in  mathematical  statistics  the  word  'event' 
has  the  broadest  meaning,  that  of  any  proposition,  whether  true  or  not.  The  event  con- 
cept has  even  been  taken  as  a primitive  (i.e.,  as  undefined)  and  then  used  to  define  the 
series  of  time  points  (Weiner  1914;  Hussell  1966). 

To  deal  with  event  reports  it  was  necessary  to  defino  a 'data  semantics'  and  a 
corresponding  Fvenl  Representation  language  which,  as  the  name  implies,  is  a special 
language  for  the  description  of  events  and  event-related  concepts,  such  as  objects, 
processes,  and  other  entities.  This  language  also  has  the  desirable  feature  of  being 
representable  in  an  appropriate  formalism  (see  Section  3),  which  is  amenable  to  com- 
puter processing.  I his  language  guides  the  mapping  process  which  converts  narrative 
text  into  formatted  event  records  (see  Section  3.4). 

By  an  event  we  mean  roughly  either  the  property  that  an  object  has  at  a point  In  time  or 
over  a time  interval,  or  a relation  that  holds  among  a set  of  objects  or  locations  at  a 
point  in  time  or  over  a time  interval. 

Events  may  be  gathered  into  certain  event  classes  called  activities,  e.g.,  air  activities, 
submarine  activities,  and  ground  activities.  These  are  characterized  as  involving  certain 
types  of  objects  or  properties  or  relations. 

We  give  a classification  of  events  based  on  considerations  involving  sources  of  reports, 
observers  of  events,  and  relations  and  properties  Involved  in  events.  Time  points  are 
the  central  element  of  an  event.  A discussion  of  time  data  as  it  occurs  in  natural 
language  Is  given  in  Kuhns  and  Montgomery  (1973)  and  Kuhns  (1976). 

The  most  complicated  examples  arise  in  messages  containing  narrative  text.  These 
Illustrate  the  variety  of  problems  that  arise  In  defining  events  and  the  necessity  for 
their  classification.  One  example  Is: 

A reliable  source  reported  that  water  tankers 
accompanied  by  trucks  carrying  what  appears  to 
be  ...  have  been  observed  stopping  ...  . This 
could  indicate  that  ...  . 

The  initial  analysis  of  the  first  sentence  shows  that  this  involves  four  levels  of  events. 
There  is  first  the  fact  that  water  tankers  wore  accompanied  by  trucks,  etc.;  there  is 
second,  the  observation  of  the  fact;  third,  there  is  the  report  of  the  observation  (i.e.,  via 
the  referenced  source);  and  finally,  there  Is  the  message  ttsell  which  is  a report  of  a 
report.  To  distinguish  these  levels,  we  introduce  the  notion  of  a meta-event 

We  define  a meta-evont  to  be  a report  of  an  event.  There  are  two  sorts  of  events 
other  than  meta-events:  an  observational  event  which  is  a direct  perception  of  an  event 
(often  indicated  as  a visual  perception,  e.g.,  'observe,'  'sight';  an  electronic  perception, 
e.g.,  'contact';  or  a term  ambiguous  as  to  the  nature  of  the  contact,  e.g..  ’identify,* 
'detect');*  and  a primitive  event  which  does  not  involve  an  observation.  The  meta- 
events  themselves  are  distinguished  by  orders.  A meta-event  that  reports  on  an  obser- 
vational or  primitive  event  is  a first  order  meta-event. 

A meta-event  that  reports  on  nth  order  meta-events  is  an  (nr-l)th  order  meta-event. 
Thus  the  previous  example  message  is  a second  order  meta-event  reporting  a first  order 


♦ A special  case  of  an  observational  event  ts  a designation  event  where  a special 
proper  name  for  an  object  is  introduced,  e.g.,  'an  aircraft,  designated  as  MiG-21,...' 


meta-event  consisting  of  an  observational  event  of  a primitive  event. 

A similar  analysis  can  be  given  for  the  example: 

It  is  reported  that  two  Ugandan  r class  fighter  aircraft 
were  sighted  in  the  vicinity  of  0200S32301  at 
011  200  hours. 

Here,  the  originator  of  the  message  uses  a passive  sentence  construction  rather  than 
stating  the  source  of  tho  report.  This  too  is  a second  order  meta-event  describing  a 
first  order  meta-event  describing  an  observational  event  of  a primitive  event. 

The  meta-events  can  be  considered  to  convey  certain  pragmatic  information  that  is  of 
Importance  to  the  intelligence  analyst,  lhe  most  Important  aspect  of  this  pragmatic 
Information  relates  to  the  credibility  of  the  event  data  bolng  reported.  Other  aspects 
are  fact  of  the  message  transmittal  itself,  the  time  and  origin  of  transmittal,  etc.  The 
decision  making  function  related  to  the  pragmatic  information  involved  is  one  of  feed- 
back. Just  as  for  other  sensors:  to  reorient  the  data  collection,  to  suspend  it,  or  amplify 
It. 

Since  a messago  is  itself  a report  of  an  event,  it  is  a first  order  meta-event. 

A further  breakdown  is  used  for  primitive  events.  We  distinguish  two  kinds.  An  attribu 
tive  event  gives  a situation  where  a particular  object*  or  object  of  a certain  type  lias  a 
certain  attribute  (other  than  spatial  location),  which  may  be  inherent  or  temporally  con- 
strained: I.e.,  the  attribute  is  true  at  a certain  time,  or  in  a certain  time  interval. 

Thus,  the  example: 

the  aircraft  Is  Y-class 

Is  an  attributive  event.  In  the  notation  of  the  predicate  calculus  an  attributive  event  is 
symbolized  as: 

P(x.t)  (1) 

where  x Is  the  object  argument,  t Is  the  time  argument  and  P is  the  attribute  that  x has 
at  time  t. 

The  argument-expression  ’x’  can  have  a variety  of  forms  through  which  additional  pro- 
perties of  the  object  can  be  expressed  --  chiefly  through  the  use  oi  descriptive 

phrases. 

The  second  kind  of  primitive  event  is  called  a relational  event.  This  is  a situation  where 
n objects  or  an  object  and  a location  stand  In  some  relation  to  each  other  at  a certain 
time.  Position  data  may  be  absent,  but  when  it  occurs  with  ono  object-argument,  then 
the  relational  event  gives  either  the  location  relation  holding  between  an  object  and  its 
position  at  a certain  time  (e.g.,  the  primitive  event  described  in  tho  second  example)  or 
some  other  relation  between  n objects(e.g.,  'the  aircraft  entered  Biafran  airspace’). 

A relational  event  is  symbolized  as: 

R(x1, xn,t) 


* Objects  are  taken  In  the  broadest  sense  and  include  cultural  objects  (such  as 
governments,  Institutions,  etc.),  and  psychological  objects  (perceptions,  attitudes, 
etc.). 
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where  xl xn  are  object  or  location  arguments,  and  t is  the  time  argument.  Among  the 

relational  events  Is  a class  of  special  interest  --  those  are  events  giving  a woild  point 
of  an  object,  i.e.,  its  space-time  coordinates.  Such  an  event  is  called  a locution  event. 
or  world  point  event. 

Thus,  the  track  of  an  aircraft,  which  consists  of  a set  of  world  points,  is  a portion  of  Its 
world  line.  For  a location  event,  the  expression  (2)  then  takes  the  form: 

L(x,p,t)  (3) 

where  p is  the  location  argument. 

Another  class  of  relational  events  is  given  by  a generalization  of  (3).  These  we  call 
world  point  qualif ications  or  location-event-qualifications.  Such  an  event  is  a two-place 
relation  (other  than  location)  between  an  object  and  a location  that  holds  at  a certain 
time.  Thus,  the  relation  stipulates  the  activity  of  an  object  at  a certain  point  and  timo, 
e g.,  an  aircraft  flying  south  In  the  vicinity  of  ...  at  ...  . In  symbols  this  is  expressed  as. 

Q(x.p.t)  (4) 

where  Q Is  the  activity  engaged  in  by  x at  the  space-time  point  (p,t). 

In  an  event  record  we  can  consider  the  world  point  of  an  object  to  be  a property  of  the 
object  This  propei ty  can  be  defined  formally  through  use  of  the  \-operator  which  is 
used  in  logic  to  introduce  new  predicates  (i.e.,  names  of  attributes  or  relations).  Thus, 
the  world  point  property  corresponding  to  (3)  is  written  as: 

P=(\x)  t(x,p,t)  (5) 

or  as  coordinates: 

(p.t)  = (\x)  L(x,p,t)  (6) 

For  example,  in  the  second  example  above: 

(p,t)  = (In  the  vicinity  of  0200S  3230F,  01  1200) 

Similarly,  a world  point  qualification  can  be  expressed  as  a triple  giving  the  space-time 
point  of  the  object  and  its  attribute.  For  this  we  write: 

(p,t,Q)  = (\x)  Q(x.p.t)  (7) 

An  example  of  a world  point  qualification  would  be: 

(p,t,C)  = (0200S  32301,0 1 1200,  moving  not  at  all) 

In  all  these  formulations,  we  are  treating  the  time  arguments  on  a logically  different  level 
from  the  object  and  location  arguments.  The  reason  for  this  is  that  time  arguments 
always  occur  in  event  formulations  (even  though  sometimes  only  implicitly)  while  other 
arguments  need  not  occur. 

If  an  event  involves  two  or  more  objects  or  locations  It  is  called  simply  a non-world  point 
event,  because  It  is  not  uniquely  classified  by  object  and  location.  However,  many  such 
events  can  be  reduced  into  world  point  events  or  qualifications.  For  example,  'John  met 
Mary  at  ...’  can  be  reduced  by  use  of  the  \-operator)  to  either  a property  of  John  (and 
hence  a world  point  qualification  event)  or  a property  of  Mary  (similarly).  Also,  for  exam- 
ple, ’The  aircraft  flew  from  London  to  Paris'  splits  into  two  world  point  events  for  the 
same  object  — a departure  at  London  and  a (later)  arrival  at  Paris 


A summary  of  the  classification  of  events  is  given  in  Table  2-1. 

In  the  symbolism  above,  we  have  broken  a primitive  event  into  object,  location,  and 
time-arguments  and  relations  and  properties.  Indeed,  every  situation  can  be  so 
analyzed.  This  has  been  referred  to  in  the  literature  as  thing-splitting  [Reichenbach, 
1947].  It  is  often  more  natural  to  introduce  events  themselves  as  arguments  — for 
example,  in  the  analysis  of  meta-events  or  observational  events.  Thus,  a meta-event 
can  be  symbolized  as: 

R(s,e,t)  (8) 

which  describes  a report  of  e by  source  s at  time  t. 

Similarly  an  observational  event  is: 

0(x,e,t)  (9) 

which  describes  the  observation  of  e by  the  observer  x at  time  t. 

Table  2-1.  Classification  of  Events 


Meta-events 
Non-meta  events 

Observational  events 
Primitive  events 

Attributive  events 
Relational  events 

World  point  events  (location  events) 

World  point  qualification  events 
(location  event  qualifications) 

Non-world  point  events,  or  events  involving 
two  or  more  objects  or  locations 


The  Introduction  of  events  (even  those  corresponding  to  primitive  events)  as  arguments 
In  situations  can  be  achieved  by  certain  symbolic  devices.  This  is  called  event-splitting 
(Reichenbach, 1947),  i.e.,  the  situation  is  ’split’  conceptually  into  an  event-argument  and 
an  event  property.  Language  has  various  devices  for  event-splitting,  the  chief  one 
being  nominalization,  e.g.,  ’arrival,’  and  the  use  of  the  word  ’that’  which  flags  an  event- 
argument.* 

Primitive  events  can  be  further  concatenated  into  event  chains  which  are  a sequence  of 
minor  events  giving  an  initiation,  continuation,  or  termination  of  certain  major  events.  For 
example,  the  major  events  of  aircraft  penetration  could  include  such  minor  events  as  the 
Initial  penetration  of  airspace,  the  reaction,  and  a termination  such  as  the  departure  or 
destruction  of  the  aircraft.  Observational  events  can  also  be  gathered  into  event 
chains.  Establishing,  maintaining,  losing,  and  regaining  contact  with  an  aircraft  provides 
an  example  of  this.  Another  use  of  event  chains  is  the  monitoring  of  minor  events  to 
forecast  major  events.  The  definition  of  interval  events,  i.e.,  activities  which  continue 
over  an  interval  of  time  (as  opposed  to  point  events),  can  be  accomplished  by  reducing 
them  to  point  events.  This  is  accomplished  by  defining  an  event  type,  such  as  flying, 


A formal  method  for  introducing  event  arguments  is  described  in  Kuhns  (1975). 
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and  then  stating  that  an  event  of  this  type  occurred  at  every  point  in  a time  interval.  In 
English,  interval  events  are  usually  associated  with  the  progressive  tenses.  (Verb 
tenses  furnish  important  implicit  time  data  of  a relative  nature  (Kuhns  and  Montgomery 
(1973)  and  Kuhns  (1974). 

While  an  observational  event  involves  the  perceptional  facility  of  an  observer,  there  are 
other  events  involving  the  evaluative  facility  of  an  observer,  source,  or  person.  These 
are  events  dealing  with  appraisals  of  an  object  property,  a truth  value  for  occurrence  of 
an  event,  and  a degree  of  belief  in  an  event.  An  example  is  given  by  the  first  message 
sentence  (above).  Thus,  the  phrase  what  appears  to  be’  flags  the  evaluation  of  an 
object-property. 

The  phrase  beginning  the  second  sentence  'Ibis  could  indicate  that'  flags  a hypothetical 
event,  i.e.,  one  that  is  not  asserted  as  occurring  but  only  as  possible  or  predicated. 
Similarly,  the  phrase  'a  reliable  source’  is  an  evaluative  component  of  the  message.  !t 
would  seem  that  these  evaluations  should  be  distinguished  from  affirmative  or  direct 
assertions  such  as  'determined  to  be,’  'confirmed  to  be,’  'the  previous  report  is  errone- 
ous' even  though  these  can  be  considered  as  extreme  cases  of  evaluations,  just  as  any 
report  can  be  so  considered.  We  can  say  that  an  evaluative  component  of  an  event,  or 
an  evaluative  event  itself  (e.g  , this  could  indicate  that  ...),  is  one  that  expresses  the 
reporters  subjective  judgment  of  the  information  conveyed.  These  notions  are  tentative 
and  should  be  subject  to  further  study.  For  the  time  being,  we  class  an  evaluative 
event  as  a special  kind  of  meta-event.  It  seems  that  an  evaluative  component  of  an 
event,  such  as  the  appraisal  of  an  object-property,  can  be  analyzed  as  the  conjunction 
of  an  evaluative  event  and  a primitive  event,  and  that  this  approach  can  be  consistently 
carried  through. 

2.3  The  Concept  of  a Template 

In  this  section  the  concept  of  a template  is  explicated  from  two  points  of  view.  First,  the 
focus  is  on  those  properties  which  render  it  particularly  useful  as  an  analytical  tool; 
then,  the  focus  shifts  to  its  internal  organization  as  a knowledge  structure  for  the 
representation  of  event  data. 

2.3.1  The  Template  as  an  Analytical  Tool.  In  this  section  we  present  a general  view  of 
the  template  as  an  information  structure  for  the  description  of  event  data  with  particular 
emphasis  on  those  features  that  render  it  useful  to  the  analyst  in  his  task. 

The  template  as  the  basic  knowledge  structure  for  the  compact  and  uniform  representa- 
tion of  information  on  entities  and  events  described  In  intelligence  messages  provides 
the  means  of  coding  the  analyst’s  cognitive  models  in  terms  of  logical  data  structures 
which  are  susceptible  to  automated  processing. 

An  event  template  Is  composed  of  a set  of  Information  parameters  or  descriptors  which 
represent  the  type  of  information  that  answers  the  set  of  questions  shown  in  Table  2-2, 
which  also  illustrates  the  corresponding  descriptors  of  a prototype  template. 


This  Is  somewhat  of  an  oversimplification  of  the  template  concept  for  convenience  of 
presentation,  since  complex  descriptors  within  the  template  are  actually  represented  by 
pointers  to  other  types  of  templates:  e g.,  object  templates.  Thus  for  the  message 
given  in  example  a),  an  object  template  reflecting  an  aircraft  description  is  essentially 
embedded  in  the  event  description  by  a pointer  reference,  as  shown  in  Table  2-3: 
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TABLE  2-2.  Information  Parameters  of  a Prototype  Template 


QUESTION 

DESCRIPTOR 

EXAMPIF 

what 

event  type 

airspace 

who 

agent  (or  object 
plus  owner) 

a Ugandan  MIG-21 

when 

time  of  event 

at  0205/  25  April  19/8 

where 

location  of 

event  occurrence 

8 miles  from  the  Konya 
border  near  Suam 

to  whom 

patient,  or  entity 
affected  by  the  event 

probable  reconnaissance 
mission 

(a)  TWO  SAAF  CAPETOWN-BASED  SAG22  ACF1  ABE  OPERATING  OVER  THE 
INDIAN  OCEAN. 

It  Is  interesting  to  note  that  message  a)  is  incomplete  in  terms  of  the  prototype  template 
specification  outlined  in  Table  2-2.  Conspicuously  absent  is  a time  descriptor  * 

For  the  formal  description  of  the  event  in  (a)  to  be  complete,  a time  descriptor  element 
must  be  satisfied.  The  absence  of  this  element  can  be  signalled  to  the  analyst  to  indi- 
cate that  this  element  must  be  supplied  for  the  information  representation  to  be  com- 
plete. Thus,  infra  -template  relations  — the  set  of  relations  connecting  descriptors 
within  a template  — provide  an  important  means  of  alerting  analysts  to  the  missing  infor- 
mation elements  in  data  structures  constituting  subparts  of  the  network  of  templates 
which  represents  an  analyst’s  cognitive  model  of  a state-of-affairs. 

Another  set  of  relations  which  can  be  very  useful  to  the  analyst  are  relations  between 
templates,  or  inter  -template  relations. 

For  example,  an  aircraft  cannot  fly  unless  it  has  taken  off,  cannot  land  unless  it  has 
been  flying,  must  be  in  flight  if  it  has  taken  off  and  has  not  landed  or  been  destroyed. 
Thus  a TAKE-OFF  is  a template  which  represents  a necessary  predecessor  event  to  a 
FLIGHT  event.  On  the  other  hand,  a l AND  event  is  a possible,  but  not  obligatory  succes- 
sor to  a FLIGHT  event,  for  the  object  involved  in  the  flight  may  have  changed  course,  or 
may  have  been  destroyed  before  landing. 

fnter-template  relations  predict  the  normal,  expected,  ordering  of  events  in  the  air 
activities  world.  Any  violation  of  these  expectations  can  serve  as  a warning  to  the 
analyst  that  some  external  force  has  altered  the  predicted  course  of  events.  It  is 
therefore  important  that  the  analyst  be  alerted  to  any  deviation  from  the  expected. 


* Also  a separate  template  because  of  the  complexity  of  most  time  descriptors,  which 
are  derived  only  partially  from  explicitly  stated  times  as  in  the  Table  2-2  example; 
they  must  often  be  reconstructed  from  the  tense  of  the  internal  verbs,  time 
operators  such  as  ’currently’,  which  point  to  information  in  the  message  header  or 
the  textual  context  of  the  time  referent,  and  the  internal  structure  of  a time 
descriptor,  which  may  read  ’at  10  minute  intervals  for  a period  of  6 hours'. 


Table  2-3  Content  Representation  for  Sentence  (a). 


EVENT  DESCRIPTION 


UNIT  REPRESENTED:  EVENT 
EVENT  TYPE:  BE  ACTIVE 


OBJECT: 


REGION: 


THE  INDIAN  OCEAN 


1 

1 

1 

1 

1 

1 

AIRCRAFT  DESCRIPTION 

1 

1 

1 

1 

UNIT  REPRESENTED: 

OBJECT 

1 

1 

1 

OBJECT  TYPE: 

AIRCRAFT 

1 

1 

TYPE: 

SA622 

1 

SUBORDINATION: 

SOUTH  AFRICAN  FLEET  AIR  FORCE 

1 

1 

BASE: 

CAPETOWN-BASED 

1 

1 

1 

1 

SET  SPECIFICATION: 

TWO 

Accordingly,  the  explicated  network  of  inter  template  relations,  both  obligatory  and 
optional,  provides  an  additional  means  of  alerting  the  analyst  to  the  implications  of  an 
event,  as  well  as  to  related  events  which  may  furnish  data  elements  missing  in  the  tem- 
plate currently  being  processed. 

In  summary,  the  application  of  template  technology  to  the  analysis  of  narrative  text  can 
provide  an  important  analytical  aid  from  the  following  five  points  of  view: 

• Templates  constitute  a powerful  means  for  distilling  the  content  of  verbose  tex- 
tual messages  into  a compact  format. 

• Templates  are  logical  information  structures  which  can  be  used  to  represent  the 
analyst’s  cognitive  models  of  events  and  states  of  affairs. 

• Inter  and  Intra  template  relations  can  assist  the  analyst  in  recognizing  missing 
elements  of  information  and  predicting  future  events. 
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• Templates  provide  a discrete  representation  of  an  event  which  lends  itself  readily 
to  statistical  analysis,  as  in  indications  monitoring  applications  for  l&W. 

• Event  data  available  from  the  TIME  and  LOCATION  descriptors  of  templates  can  be 
exploited  to  drive  automatic  plotting  of  ship,  submarine,  and  aircraft  tracks. 

2.3.2  The  Internal  Structure  of  the  Template. 

Information  contained  in  templates  is  of  two  types:  declarative  information  and  pro- 
cedural information.  We  begin  our  discussion  with  a preliminary  specification  of  the 
declarative  elements  of  the  template  and  the  relations  between  those  elements.  Next, 
we  present  the  procedural  components  of  the  template  and  consider  the  operations  they 
perform. 

2.3.2. 7 Structure  of  the  Template:  Descriptive  Elements  Essentially,  a template  is  a 
data  structure  which  has  a unique  "name"  and  an  ordered  set  of  "slots"  filled  by 
"descriptors".  Template  "names"  serve  as  identifiers  and  refer  to  the  entity  described 
by  the  template.  Examples  of  template  names  in  the  air  activities  domain  are:  BE 
ACTIVE,  FLY,  DEPLOY,  ARRIVE,  AIRCRAFT,  and  DTG  (date-time  group). 

The  substructure  of  a template  and  its  relations  to  other  templates  is  defined  in  its 
descriptor  slots.  Descriptors  bear  special  meaning  relations  to  the  central  concept. 
Each  descriptor  slot  names  some  property  of  that  concept.  For  example,  most  event 
templates  involve  the  descriptor  slot  "Object",  which  names  the  relation  of  the  entity 
which  fills  this  slot  to  the  event.  In  general,  descriptors  are  of  several  types.  Some 
may  assign  an  object  to  membership  in  a category  (such  as  "is  an  aircraft");  others  may 
state  an  object’s  functional  rote  in  a complex  event  (the  "Source"  of  a particular  flight); 
yet  others  may  express  the  time  and  place  of  an  event  ("at  0115Z";  "along  the  River 
Kwai"). 

Each  descriptor  slot  has  a name  which  is  unique  within  the  template.  Associated  with 
each  descriptor  slot  is  a set  of  one  or  more  statements  which  constrain  what  may  "fill" 
the  corresponding  slot  in  the  representation  of  an  individual  entity.  These  statements 
will  be  referred  to  as  "filler  specifications".  Filler  specifications  then,  give  linguistic 
Information,  i.e.,  they  specify  how  a particular  descriptor  can  be  realized  in  the  sub- 
language. A filler  specification  indicates  the  possible  deep-structure  syntactic  environ- 
ments for  a given  descriptor  as  well  as  the  properties  of  the  items  to  which  the  rules 
which  map  syntactic  trees  onto  meaning  representations  are  sensitive.  Thus,  the 
description  associated  with  the  ’Object’  descriptor  in  the  DEPLOY  template  for  the  air 
activities  domain,  would  specify  that  the  object  is  normally  an  aircraft.  In  the  descrip- 
tion of  an  individual  event  of  the  DEPLOY  class,  this  is  further  specified  as  some  specific 
aircraft,  (e.g.,  a Nairobi-based  F-4  Phantom  fighter).  The  descriptors  associated  with 
the  DTG  template,  on  the  other  hand,  specify  the  permitted  range  of  values  for  its  com- 
ponents (see  Table  2-4).  For  example,  the  day  in  a particular  month  must  lie  within  the 
lower  limit  of  1 and  an  upper  limit  equal  to  the  length  of  the  corresponding  month.  A day 
number  of  77  would  be  outside  the  permissible  range  of  variation  for  this  descriptor.  If 
such  an  anomaly  is  discovered,  it  must  be  brought  to  the  attention  of  the  analyst  operat- 
ing the  system. 

Any  descriptor  of  a template  can  be  defined  as  a separate  template  when  its  internal 
description  is  important  to  the  analyst  and  is  of  sufficient  complexity  to  warrant  a 
separate  representation.  For  instance,  the  template  for  the  DEPLOY  event  class  incor- 
porates a descriptor  "Object",  whose  attribute,  in  this  template,  is  "aircraft".  But  "air- 
craft" In  Itself  is  a complex  notion  of  l&W  significance  and  is  represented  by  a template 
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of  its  own  (see  Tab'e  2-3  above). 


The  template  as  a unit  for  representing  knowledge,  therefore,  is  complex  and  extensive. 
Rather  than  being  of  the  order  of  a single  property  or  relation  attributed  to  the  entity 
described,  it  is  an  n-plaoe  hierarchical  relational  definition  of  a concept  with  optional 
pointers  indicating  relations  with  other  templates. 


In  summary,  the  descriptive  elemonts  incorporated  In  a template  represent  the  analyst’s 
knowledge  of  concepts  and  their  interrelationships  in  his  particular  task  domain. 

Table  2-d.  Description  of  the  Date-Time  Concept  (DTG) 


TEMPLATE  NAME 


DTG  (DATE-TIME  GROUP) 


DESCRIPTOR  NAME 


FILLER  DESCRIPTION 


Day-number 


Zulutime 

Time 

Month 

Year 


First  two  digits  of  seven 
character  string  of  format 
NNNNNNZ.  Constraints: 

max  day  number  = Month  Length 

time  concatenated  with  "Z". 

Four  digit  string  with 
constraints: 

0000  < Time  < 2400 

Three  character  string. 

Member  of  set  (Jan,  Feb,  Mar, 
Apr, May,  Jun,  Jul,  Aug,  Sept, 
Oct. Nov, Dec) . 

Two  digit  string  constraints: 

1st  digit  = 7 
2nd  digit  = 9 


2.3. 2. 2 Structure  of  the  Template:  Procedural  Components  As  mentioned  previously, 
templates  are  active  data  structures  which  Incorporate  both  declarative  and  procedural 
knowledge.  This  section  is  concerned  with  the  procedural  components  of  templates  and 
how  these  are  used  by  the  system  throughout  the  process  of  narrative  text  analysis. 

Procedures  are  attached  to  descriptor  slots.  They  are  essentially  mapping  rules  which 
effect  the  transformation  of  parsed  sentences  into  event  records.  Procedures  carry 
out  specific  computations.  Some  define  the  steps  involved  in  finding  "fillers"  for  partic- 
ular descriptors,  others  specify  the  operations  involved  in  identifying  the  referents  of 
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anaphoric  expressions,  while  yet  others  may  compute  relations  between  events. 

These  mapping  rules  are  necessarily  language  specific.  They  incorporate  the  domain- 
specific  pragmatic  knowledge  which  establishes  the  link  between  the  abstract  descrip- 
tion of  an  event  class  (the  template)  and  the  description  of  an  individual  member  of  that 
class  (the  event  record). 

The  process  of  "understanding"  a sentence  consists  of  an  Interaction  between  the  pro- 
cedures associated  with  the  descriptor  slots  of  the  corresponding  template,  each  of 
which  actively  seeks  to  satisfy  its  own  requirements.  Essentially  this  is  done  by 
searching  the  parse  tree  for  constituents  which  satisfy  the  syntactic  and  semantic  con- 
straints on  the  permissible  fillers  for  a particular  descriptor. 

It  should  be  noted  here  that  not  all  descriptor  slots  in  a template  need  be  filled  for  any 
particular  input  sentence.  A template  provides  slots  as  placeholders  for  information  that 
Is  considered  relevant,  even  though  it  may  not  always  be  present  in  the  input.  The 
number  of  slots  of  any  template  that  will  be  filled,  therefore,  depends  largely  on  the 
Information  contained  in  the  input  sentence.  It  is  important  to  note,  however,  that,  for  a 
sentence  to  be  considered  as  "understood",  the  following  two  conditions  must  be  met: 

• Every  element  of  the  input  sentence  must  be  assigned  to  some  descriptor  slot; 

• All  "obligatory"  descriptor  slots  must  be  filled. 


1-17 


3.0  The  Event  Representation  Language 

3.1  Introduction 

The  Event  Representation  Language  (ERL)  developed  under  this  contract  is  an  experi- 
mental language  especially  written  to  explore  the  use  of  "templates"  as  a knowledge 
representation  technique  with  which  to  build  systems  for  message  text  analysis  in  sup- 
port of  l&W  functions.  The  basic  data  objects  of  ERL  are  the  templates. 

ERL  Is  Implemented  In  a subset  of  Prolog,  an  Interactive  programming  language  based 
upon  a simple  but  efficient  proof  procedure  involving  a subset  of  classical  logic  referred 
to  as  "Definite  Clauses"  (van  Emden,  1975).  The  basic  computational  mechanism  of  Pro- 
log, and  therefore  of  ERL,  is  a pattern  matching  process  (’unification’)  operating  on  gen- 
eral record  structures  (’terms’  of  logic).* 

Prolog  was  Initially  developed  at  the  University  of  Marseilles  (Roussel  1975)  as  a practi- 
cal tool  for  ’logic  programming’  (Kowalski  1974;  Colmerauer  1976;  van  Emden  1975),  and 
has  since  been  used  in  several  other  centers  (Stanford,  Edinborough)  for  writing 
language  analysis  systems  (Dahl  1977;  Warren  1977a,  Warren  1977b). 

Prolog  is  a perspicuous  and  powerful  language  for  the  expression  of  the  concepts  of  our 
Event  Representation  Language,  and  admits  of  an  effective  and  reasonably  efficient 
Implementation.  Clear,  readable,  concise  programs  can  be  written  quickly  and  with  few 
errors.  Specifically,  the  following  features  make  it  particularly  suitable  for  our  purposes: 

• Pattern  matching  (unification)  replaces  the  conventional  use  of  selector  and  con- 
structor functions  for  operating  on  structured  data. 

• The  arguments  ol  a procedure  can  serve,  not  only  for  it  to  receive  one  or  more 
values  as  input,  but  also  for  It  to  feturn  one  or  more  values  as  output.  Procedures 
can  thus  be  "multi-output"  as  well  as  "multi-input". 

• The  input  and  output  arguments  of  a procedure  do  not  have  to  be  distinguished  in 
advance,  but  may  vary  from  one  call  to  another.  Procedures  can  thus  be  "multi- 
purpose". 

• Procedures  may  generate  (via  backtracking,  in  the  case  of  Prolog)  a set  of  alter- 
native results.  Such  procedures  are  called  "non-determinate".  Backtracking 
amounts  to  a high-level  form  of  iteration. 

• Procedures  may  return  "incomplete"  results,  i.e.,  the  term  or  terms  returned  as  the 
result  of  a procedure  may  contain  variables,  which  are  only  filled  in  later,  by  calls 
to  other  procedures.  The  effect  is  similar  to  the  use  of  assignment  in  a conven- 
tional language  to  fill  in  fields  of  a data  structure.  Note,  however,  that  there  may 
be  many  occurrences  of  an  instantiated  variable,  and  that  all  of  these  get  filled  in 
simultaneously  (in  a single  step)  when  the  variable  is  finally  instantiated.  Note 
also  that  when  two  variables  are  unified  together,  they  become  identified  as  one. 
The  effect  is  as  though  an  Invisible  pointer,  or  reference,  linked  one  variable  to 
the  other.  We  refer  to  these  related  phenomena  as  the  "logical  variable". 

• "Program"  and  "data"  are  identical  In  form.  A procedure  consisting  solely  of  unit 
clauses  is  closer  to  an  array,  or  table  of  data,  in  a conventional  language. 

* For  a full  description  of  the  syntax  and  semantics  of  Prolog,  see 
Appendix  B. 
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Section  3.2  shows  how  Prolog  is  used  for  encoding  templates  and  their  associated  pro- 
cedures. Section  3.3  explains  the  ERL  procedures  so  far  developed  for  event  record 
synthesis,  while  section  3.4  offers  a detailed  example  of  how  templates  written  in  ERL, 
and  executed  as  a Prolog  program  behave  as  a semantic  interpreter  for  the  syntactic 
structures  output  by  the  ATN  parser. 

3.2  How  Templates  are  Expressed  in  Prolog 

In  the  following  paragraphs  we  describe  the  formalism  used  for  the  abstract  specifica- 
tion of  both  the  data  structures  (templates)  and  the  procedures  of  ERL,  and  show  how 
they  are  expressed  in  the  programming  language  Prolog. 

In  ERL,  both  templates  and  template  slots  are  encoded  as  Prolog  procedures.  A Prolog 
procedure  consists  of  a sequence  of  statements  called  clauses.  A clause  comprises  a 
head  and  a body.  The  head  corresponds  to  a procedure  call,  while  the  body  represents 
conditions  to  be  fulfilled  for  the  head  to  be  satisfied.  The  general  format  of  a Prolog 
clause  is  as  follows: 

• head:-  body. 

The  head  consists  of  one  Prolog  goal,  while  the  body  may  consist  of  a sequence  of  one 
or  more  such  goals.  Goals  correspond  to  Prolog  terms,  which  have  the  general  form: 

• functor(arg1 , arg2 argn) 

Templates  are  encoded  as  ’construct’  clauses.  For  example,  the  DEPLOY  template,  which 
is  informally  represented  in  Table  3-1  in  a simplified  form,  is  encoded  as  in  Table  3-2. 

Table  3-1.  Informal  Description  of  the  DEPLOY  Concept 


+ 

- + 

1 

1 

Descriptive  Elements 

1 1 Procedural  Elements 

1 1 

1 

1 

1 

1 

IOBL/ 

1 I Procedures 

1 

1 

1 

1 / 

1 1 for 

1 

1 Descriptor 

1 Filler  Specification 

I /OPT 

1 1 f ill ing  slots 

1 

lObject 

1 Logical  Subject 

IOBL 

II  Construct  'aircraft' 

1 

1 

1 noun  phrase 

1 

1 1 template  from  logical 

1 

1 

1 (+acft) 

1 

1 1 subject 

1 

1 1 

1 Destination  1 PP: 'to'+  NP(+loc) 

1 

IOBL 

1 1 

1 ISearch  VMODS  list 

1 

1 

1 

1 

1 

1 1 for  appropriate 

( 

1 

1 

1 

1 Iprepositional  phrase 

1 

1 

1 

1 

1 ISearch  VMODS  list 

1 

ITime 

1 1.  Adv(+  time  + ref) 

|OPT 

1 1 for  appropriate 

1 

1 

1 2.  PP  (during, between) 

1 

I Iconstituent 

l 

1 

+ 

1 ♦ NP  (+  time) 

1 

1 1 

1 

-♦ 
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Table  3-2.  ERL  Representation  of  DEPLOY  Template 


I construct  (’ DEPLOY',  s (Subj,  Vbgr,  Obj,  Compl,  Vmods),  [OBI,  SI,  L2,  L’TG] ):  - I 
I objectl  (Subj, OBI),  I 

I destlnationl (Vmods, Dl),  I 

I construct  (’DTG’,  Vmods,  DTG) . I 

I I 

♦ «. 


The  head  of  the  "construct"  clause  has  three  arguments:  a template  name,  the  name  of 
the  syntactic  constituent  which  serves  as  the  context  which  is  searched  in  an  attempt 
to  find  fillers  for  the  descriptor  slots  of  the  template  in  question,  and  a third  argument 
which  represents  the  output  of  the  procedure,  i.e.,  the  instantiated  slots. 

The  body  of  the  ’construct’  clause  consists  of  three  'goals’  corresponding  to  the  three 
slots  of  the  DEPLOY  template  shown  In  Figure  3-2.  These  three  goals  are  themselves 
defined  as  procedures,  which  seek  fillers  for  the  descriptor  slots  they  represent. 

Procedures  for  filling  template  slots  can  be  obligatory  or  optional,  and  are  named  after 
the  slot  they  are  designed  to  fill.  Thus,  the  procedure  for  filling  a ’destination’  slot  is 
called  ’destination  1 ’,  if  it  obligatory,  and  ’destination2’,  if  It  optional.  Slot-filling  pro- 
cedures take  as  input  a syntactic  structure  and  return  a "filler",  provided  certain  condi- 
tions expressed  as  goals  are  satisfied. 

For  example,  the  ’destination!’  slot  in  the  ’construct’  procedure  for  DEP10Y,  is  written  as 
In  Table  3-3. 

Table  3-3.  A ’destination’  Clause 


♦ * 

I I 

I dest inat ion  (Vmods,  slot (’ DESTINATION* Slot) ): - I 

I fill-slot  (Vmods,  ['TO'] , ' LOG', Slot) . I 

I I 

+ • 


The  ’destination’  clause  takes  the  Vmods  list  as  input,  and  returns  a filler  which  must  be 
a prepositional  phrase  with  a preposition  ’to’,  and  an  object  nounphrase  with  the  feature 
’LOC’.  Notice  that  the  third  goal  of  the  construct  procedure  for  ’DEPLOY’  is  a call  to  the 
’construct’  procedure  for  building  a DTG  record.  For  a full  listing  of  the  procedures  for 
constructing  templates,  see  Subsection  3.3. 

It  would  appear  that  the  procedures  required  for  filling  descriptor  slots  will  cover  a wide 
spectrum,  from  those  involving  a straight  forward  match  of  two  structures,  to  those 
requiring  complex  operations  such  as  data  base  searches.  A preliminary  specification  of 
procedures  developed  for  the  analysis  of  the  air  activities  sublanguage  is  given  In  the 
next  subsection. 

3.3  ERL  Procedures  for  Event  Record  Synthesis 

in  this  section  we  present  the  set  of  'air  activities’  event  templates  and  their  associ- 
ated procedures  as  expressed  in  FRL,  the  formalism  from  which  they  will  be  compiled. 
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The  templates  developed  so  far  for  the  air  activities  domain  cover  four  types  of  entities: 
events,  objects,  relations,  and  concepts  related  to  time  and  date  (the  DTG  concept). 

Templates  have  been  developed  for  the  following  event  classes:  ’active’,  ’arrive’, 
’depart’,  ’deploy’,  ’enroute’,  ’flight’,  ’locate’,  ’penetrate’,  ’recover’,  and  ’return’.  The  only 
physical  object  currently  associated  with  a template  is  the  ’aircraft’.  How  relations  are 
encoded  in  Prolog  is  illustrated  by  the  ’precede’  template.  A special  template  has  been 
developed  for  the  date  time  group  concept  (DTG). 

In  addition  to  the  procedures  for  expressing  templates,  there  are  a number  of  other  pro- 
cedures which  serve  the  purpose  of  initiating  the  event  synthesis  process,  by  identify- 
ing the  template  required  for  the  interpretation  of  a particular  input  string.  This  is  the 
function  of  the  ’build_ER’  procedure  described  below. 

3.3.1  The  'build~ER'  Procedure  A ’build_ER'  clause  takes  as  input  a parse  tree  (or  a 
substructure  thereof),  finds  the  name  of  the  template  to  be  activated,  invokes  the 
corresponding  ’construct’  clause,  and  returns  an  event  record  (ER).  The  ’build_ER’  pro- 
cedure has  three  entry  points  corresponding  to  the  three  cases  listed  below. 


3.3. 7. 7 Input  is  a Sentence.- 

build_ER  (s(Subj,Vbgr,Obj,Compl,Vmods),temp(Name,ER)):- 
find_  t_name(Vbgr,Name), 

construct(Name,s(Subj,Vbgr,Obj,Compl,Vmods),ER). 

3.3.1 .2  Input  is  a Nominal! zed  Sentence.— 

build_ER(np(Det,L1,N(Wv_),L2),ER):- 

feat(W,’NOMZ’), 

change(np(Det,L1  ,N(W,_  ),L2),T  1 ), 
build_ER(T1,ER). 

3.3. 7.3  Input  is  a Nounphrase:- 

bulld_ER(np(Det,L1  ,Noun,L2),ER):- 
find_t_name(Noun,Name), 
construct(Name,np(Det,L1  ,Noun,L2),ER). 

’bulld_ER’  clauses  have  two  or  more  subgoals.  The  task  of  the  7find_t_name’  pro- 
cedure Is  to  Identify  the  name  of  the  template  required  for  the  interpretation  of  the 
Input,  while  the  purpose  of  the  ’construct’  procedure  is  to  fill  in  the  slots  of  the  template 
thus  identified,  i.e.,  to  construct  an  event  record  (ER).  This  event  record  is  the  content 
representation  of  the  Input.  The  ’feat’  clause  is  a built-in  procedure,  also  referred  to  in 
Prolog  as  an  'evaluable  predicate’,  ’feat’  checks  a lexical  entry  for  a given  feature.  For 
example,  in  3.2.1  above,  it  checks  the  headnoun  of  the  nounphrase  np  for  the  feature 
’NOMZ’.  Finally,  ’change’  is  a normalization  procedure  which  restores  sentential  structure 
to  nominalizations. 

3.3.2  The  'construct'  Procedure  A ’construct’  clause,  when  activated,  generates  a set 
of  subgoals  which  seek  suitable  ’fillers’  for  the  slots  of  the  template  it  embodies.  The 
output  is  a list  of  instantiated  slots  which  reflect  the  meaning  content  of  the  input.  Irf 
this  sense,  ’construct’  clauses  may  be  regarded  as  procedural  definitions  of  templates. 
’Construct'  clauses  currently  handle  four  kinds  of  entities:  events  (e.g.,  deploy),  physical 
objects  (e.g.,  aircraft),  relations  (e.g.,  precede),  and  abstract  concepts  such  as  those 


1-21 


that  pertain  to  date  and  time  indications. 

3.3.2. 1 Construct  Clauses  Embodying  Event  Templates 

3.3.2. 1.1  'active' 

constructCACTIVE’.stSubj.Vbgr, Ob  j.Compi, Vmods), 

[OBI  ,MI,L  1 ,ALT,ST2,DTG]):- 

objectl (Subj,  OBI), 
mission(s(_,_,ObJ,Compl, Vmods), Ml), 
location  1 (s(_,_,Obj,_, Vmods),  LI), 
altltude(IT,  ALT), 
status2  (IT,  ST 2), 
construct(’DTG’, Vmods, DTG). 

3.3.2. 1.2  'arrive' 

constnict(’ARRIVE’,s(Subj,Vbgr,Obj,Compl,Vmods),  [OBI  ,D2,DTG]):- 
objectl  (Subj,  OBI), 
destination2  (Vmods,D2), 
construct('DT  G', Vmods, DTG). 

3. 3. 2. 1.3  'depart' 

constructCDEPART’,s(Subj,Vbgr,Obj,Compl, Vmods), [OBI  .S1.L2.DTG]):- 

objectl  (Subj,  OBI ), 

source  1 (Vmods,  SI), 

location 2 (s(_,_,Obj._  .Vmods),  L2). 

cons  true  t('OTG',  Vmods, DTG). 

3.3.2. 1 .4  'deploy' 

construct(’DEPLOY’,s(Subj,Vbgr,Obj,Compl, Vmods),  [OBI  ,01  ,DTG]):- 
objectl  (Subj.  OBI), 
destination  1 (Vmods.DI), 
construct(’DTG\ Vmods,  DTG). 

3.3.2. 1.5  'enroute' 

construct(,ENR0UTE’,s(Subj,Vbgr,0bj,Compl.Vmods),[OB1,MI.01.DTGl):- 
objectl  (Subj,  OBI), 
mlssion(s(_ ._  ,Obj,Compl,Vmods),MI), 
destination  1 (Vmods.DI), 
construct(’DTG’, Vmods, DTG). 

3.3.2. 1. 6 'I light' 


I 


1 
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construct  ('I  UGHT’.s^ubJ.Vbgr.ObJ.Compl.Vmods), 

[OBI , Ml, l ?,S?.D?,E?,DIR.Al  T.PA.THM.OTG']):- 
object  1 (Subj,  OBI), 
mlsslon(s(_,  ,OoJ, Compl, Vmods),  Ml), 
location?  (s(  , ,Ob),  .Vmods), L2), 
source?  (Vmods. S2), 
destination?  (Vmods, 02), 
extent?  (IT,  E2), 
dlrectlon(Vmods,  DIR), 
altttudeOl,  Al  I). 
path(Vmods,  PA), 
tbem(Vmods,  I MM), 
construct('Dl  G’,1 Vmods,  DIG). 

3.3.2. 1 .7  'locate' 

construct(’tOC A 1 t ',s(Subj,Vbgr, Ob), Compl, Vmods), [ AG2,OB  1 ,1  1 ,0 1 G ]):- 
agent?  (IT.  AG2). 
objectl  (Sub).  OBI ) 
locatlonl  (s(_,.  ,ObJ, Vmods),  L 1 ), 
construct('DTG', Vmods, DIG) 

3.3.2. 1 .3  'ftenetrate' 

construct  (’PI NLTRAU  s(Subj,Vbgr, Ob), Compl, Vmods), [OBI  ,L  1 ,Al  I.OIGj) 
ob Jet: 1 1 (Sub),  OBI), 
locatlonl  (s(  , ,ObJ,  .Vmods),  LI), 

•ltltude(IT,  Al  T). 
construct(’DT  G’,  Vmods,  D I G). 

3.3. 2.1 .9  The' prtH:e<le' 

construct(’PRECtOE’,  s(SubJ,_ ,ObJ,  . ),[E  1 .1  ?])-.- 
bulld_ER(Subj,fc1). 
bulld_ER(ObJ,  E?). 

3.3.2. 1 .10  'recover* 

construct(  ’RECOVLR’,  s(Sub), Vbgr, Ob j, Compl, Vmods), | OB  1 , l - 

objectl  (Sub),  OBI), 
location  1(s(  , ,0b  J.  ,Vmods),L1), 
constructCDT  G’, Vmods, 0 1 G). 

3.3.2.1.11  'return' 

construct(’RI  1 URN", s(  Sub  j.Vbgr, Ob), Compl. Vmods), 

[OB1.D1.MI.L2.S2.DTG]):- 

object  1 (Subj,  OBI), 
destinationl  (Vmods,D1), 
mlsslon(s(_,  .ObJ.Compl.Vmods),  Ml), 
location?  (s(_,.  ,0bj,  .Vmods),  12). 
source?  (Vmods,  S?), 

Construct(’D  1 G.Vmods.0 1 G). 


3.3.2 .2  Construct  Clauses  tor  templates  Representing  Physical  Objects 

3.3.2. 2.1  'aircraft'  Note  that  'aircraft’  is  the  only  template  representing  a physical 

object  In  the  system  at  present. 

construe  t(’AIRCHAE  T'.np(Det,L  1 ,Head,L2)f[EQ,NA,SUB,SB,SE  T ]):- 
equipments  1 .Head.EQ), 
nationality(L  1 , ’nation’,  NA), 
subordination^  ?,SUB), 
stagingbaseS  2, SB), 
setspec(Det.SET). 

3.3. 2.3  Construct  Clauses  Relating  to  Date  and  lime  Concepts 

construcU’Dl  G',Vmods,[  T 1,01  ]):- 
time(Vmods,  T I ), 
date(Vmods,DT ). 

3.3.3  Procedures  for  f illing  in  Template  Slots  Ihe  predicates  used  for  filling  template 

slots  are  represented  by  slot  names.  A slot  name  followed  by  '1*  means  that  filling  it  is 

obligatory;  a slot  name  followed  by  ’2’  means  that  tilling  it  is  optional. 

3.3.3.  T 'altitude' 

altitude(s(_ Vmods),slot(’Al  1=’.  Slot)):- 

f Ul slot(Vmods,  ['at'],  'AIT',  Slot). 


altitude(_  .nil). 

3.3.3. 2 'date' 

date(Vmods,slot(’DA!E=’,l  , W, Oay, Month,  Year)):  - 

member(pp(l . W,  dat  e(Day, Month,  Year)),  Vmods). 

date(  . . nil). 

3.3.3. 3 'destination' 

destination  1 (Vmods, slot(’Dt  SllNAllON=’,Slot)):- 

fill_slot(Vmods,['TO’],’l  oC.SIot). 

destination?  (X.Y)  - destination! (X,Y). 

destination?  (_,nil). 

3. 3. 3. 4 'direction' 

dlrection(Vmads,stot(’DlRf  CTION=’,Slot)).- 

f ill slot(Vmods,  'OIR',  Slot  ). 


dlrection(_  .nil). 

3.3. 3. 5 'equipment' 

\ equipment^  ist.nnode(W.  ).slot(’EGUIPMENT=',[l  ist.WJ)):-  feat(W.’ACRAET'). 

3.3.3. 6 'location' 


location  1 (Input, slot( 'LOCATIONS’, X)):-  locat  1 (Input, X). 
locatlon2(lnput,slot(’lOCATION=’,X)):-  locat2(lnput.X). 
locatl (Input, cons(X, l ist)):-  loc(lnput.X),  locat2(lnput,List). 
locat2(lnput,cons(X,List)):-  loc(lnput.X),  locat2(lnput,List). 
locat2(_,nil). 

loc(s(_,_,,  ,_,Vmods),  Slot):- 

fill_slot(Vmads,[’ ALONG', 'AT', 'EAST  OF’.’IN', ’OVER’], 'LOC', Slot). 
loc(s(_,_,NP,_,_),NP):-  test_nhead(NP,'LOC'). 

3.3.3 .7  'mission' 


mission(s(_ ,Vmods),slot('MISSION=’,  Slot)):- 

flll_slot(Vmods,  ['AFTER',  'FROM', 'IN', 'ON').  'ACTY',  Slot). 
mission(s(_  ,_,NP,_,_),slot('MISSION=',NP)):-  test_nhead(NP,’NOMZ'). 
mlssion(_  .nil). 


3.3.3. 8  'nationality' 


nationality(List,  Feature,slot(’NATIONAUTY=',  W)):-  member(nnode(W,_  ),List), 

feat(W, Feature). 

nationaljty(L ist,  Feature, slot(’NA7IONAUTY=',W)):-  member(W.List), 

feat(W, Feature). 


nationality(_,_  ,nll). 


3.3.3.9  'object' 

objectl  (NP,slot(’OBJECl=’f  Slot)):-  test„ nhead(NP,’ACRAM  ), 

construct(’AIRCRAFT’,NP,  Slot). 

3.3.3.7  0 'path' 

path(Vmods,slot('PA I H=',  Slot)):-  fill_slot(Vmods,l'VIA’J,'LOC’.SIot). 
path(_  .nil). 

3. 3.3.1  7 'setspe c' 

setspec(dp(__ ,_  ,Num),slot(’NUMBFR=',Num). 
setspec(__,  nil). 

3.3.3. 1 2 'source' 


sourcel  (Vmods,slot('SOUHCE=‘,  Slot):-  til|_  slot(Vmods,[’FRCM' ],'l  OC'.SIot). 
Source2(X,Y):-  sourcel  (X,Y). 
source2  (_,nil). 


3.3.3.13  'stagingbase' 

Stagingbase(l  ist.slotf’SI  AGINGBASL  =’,  Slot):- 

stagingbase(_  .nil). 

3.3.3.74  'subordination' 


till_slot(List,[’AT’]. 

’LOC'.SIot) 


subordination(l  is  t, slot  (SUBORDINATION^), Slot ))- 

till slot(l  ist, ['FROM'], 'SUBNUM', Slot) 

subordination^  .nil). 
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3.3.3.15  'them'  (the  threat) 

them(Vmods,slot('TMEM=',  Slol):- 

fill_slot(\/niot1s,  [ AGAINST’],  ’NATION’,  Slot). 
them(__  ,nil). 

3.3.3.16  'time' 

time(Vmods,slot(’TIME=’,  Slot):- 

f ind_time(  Vmods, [’AT’, ’BET  WE  EN’,’BY','DURING’, ’SINCE’], ’TYME’, 
Slot). 

time(Vmods,slot(’TIME  =’,Slot):- 

find_  timo(Vmods,['AT’,‘BE  rWEEN’,’BY’,’DURING’,’SINCE’],’4DIG’, 
Slot). 

time(Vmods,slot(’TIMF=’,Slot):- 

fill_  slot(  Vmods, [’AT’, ’BETWEEN’, ’BY', ’DURING’, ’SINCE’], ’TYME’, 
Slot). 

time(Vmods,slot(’TIME=’,  Slot):- 

fill_slot(  Vmods,  ’TYME’, Slot). 

time(_  .nil). 


3.3.4  Other  Procedures 

3.3.4. 1 'tilUslot' 

fill slot(List,  Preplist,  Feature, [L 1 .Prep, NP]):- 

member  (pp(L1 , Prep, NP), List), 
member(Prepa,  Preplist),lexeq(Prep,Prepa), 
test_nhead(NP,  Feature). 

Given  the  Vmods  list,  a list  of  prepositions  Preplist,  and  a lexical  feature  Feature, 

’fill slot'  searches  the  Vmods  list  for  a prepositional  phrase  (pp),  such  that  Prep  is  a 

member  of  Preplist  and  the  headnoun  of  NP  has  the  feature  Feature,  ’fill slot’  returns 

the  prepositional  phrase  ’pp’. 

fill slot( List,  Feature, W):- 

member(Wa,  List),lexeq(W,Wa), 

feat(W,'ADVB’), 

feat(W,  Feature). 

Given  the  Vmcds  list  and  a lexical  feature  Feature,  fill slot’  searches  the  Vmods  list  for 

an  adverb  with  feature  Feature, and  returns  the  adverb. 

fill slot( NP,  Feature, NP):-  test_  nhead(NP.'LOC’). 

3. 3. 4.2  'find ■'feat' 

find_  feat(W.L.Y):- 
member(Y.L), 
feat(W,Y). 

'find_feat'  takes  as  arguments  the  dictionary  entry  of  a word  W,  a list  of  atoms  naming 
templates  available  in  the  system  (L),  and  returns  a value  for  the  variable  Y,  such  that  Y 
Is  a member  of  L,  and  Y is  a feature  of  W. 
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3. 3.4. 3 't lnd+t*name'  'Find_t_name'  Is  a procedure  for  finding  the  name  of  the  tem- 
plate to  be  activated  for  the  interpretation  of  a particular  input  structure  ’find— 1_  name’ 
has  two  entry  points  according  to  whether  the  template  name  sought  is  derivable  from  a 
verbgroup  or  from  a noun  . 

3.3. 4.3.1  The  template  name  is  derivable  from  a verbgroup.-- 

flnd_  t_name(vg(_  ,_,_,W),Name):- 

find_feat(W, [’ARRIVE’, DEPART’, DEPLOY', ’ENROUTE’, ’FLIGHT’, 

’LOCATE1, ’PENETRATE’, ’PRECEDE’,  RECOVER’, 

’RETURN’], Name). 

3.3. 4. 3. ? The  template  name  is  derivable  from  a noun.-- 

find_t_n  me(nnode(W,_  ),Name):- 

find_feat(W,[ ’AIRCRAFT’], Name). 

3.3.4. 4 'find*time' 

find_time(List,  Preplist,  Feature, [L 1 ,W,L2]):- 
member(pp(L1  ,W,L2),List), 
member(Wa, Preplist),  lexeq(W.Wa), 
member(X,L2), 
feat(X, Feature). 

3.3.4. 5 'test-nhead' 

test_nhead(np(_,_,nnode(W, _),_), Feature):-  feat(W, Feature). 

‘test-nhead’  determines  whether  the  head  noun  (W)  of  the  input  np  the  feature 
Feature. 

3.3.4. 6 Listdefinition 
Nst([]). 

llst(X,L):-  list(L). 

3.3.4. 7 Listmembership 

member(X,[X,.._  ]). 
member(X,[_,..L]):-  rr,ember(X,L). 

3.3.5  Syntactic  Normalization  Rules. 

3.3.5. 1 NominalizatJons.  The  rules  listed  below  apply  to  nominalizations  in  subject  posi- 
tion and/or  nominalizations  in  object  position. 


3.3.5. 1.1  Restructuring  'Passive'  Nounphrases. 

Example:  A WEATHER  RECONNAISSANCE  FLIGHT  BY  ONE 
PRETORIA  BASED  SP-2S6  B-80  (BEACON) 

TO  THE  CAPE  VERDE  ISLANDS. 

change(np(Det,[L1,X],  nnode(W,0),[X  1 ,pp(_,by,Y),X2]), 

s(Y,vg(_,_,_,W),np(Det,L1,nnode(X,0),[]),_,[X1,X2])):- 

test_  nhead(Y,'NOMZ’). 
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3.3.5. 7.2  Restructuring  'Active'  Nounphrases 

Examplel:  UAF  B-76  DEPLOYMENTS  TO  MAURITIUS 

change(np(Det,[L  7 ,X],nnode(  W,0),L2), 

s(np(Det,L  1 ,nnode(X,0),[]),vg(_  ,W),0,0,L2)). 

Example2:  DEPLOYMENT  OF  7 2 AIRCRAFT  TO  KIGALI 

change(np(Det  7 ,L  1 , nnode(W1  ,pp(_,of,np(Det2,  L2,nnode(W2,0), []))),  L3), 
s(np(0,[L2],nnode(W2,0),[]),vg(_,_,_  ,W7  ),0,0,L3)):- 

7eat(W2,’acraft’). 


3.4  Event  Record  Synthesis,  an  Example 

Before  presenting  an  example  of  how  templates  are  executed  by  ERL,  a word  should  be 
said  about  the  control  mechanism  employed  by  the  system. 

3.4.7  The  ERL  Control  Mechanism.  Prolog  provides  a remarkably  simple  form  of  control, 
which  suffices  for  many  practical  applications. 

The  declarative  semantics  of  Prolog  clauses  is  such  that  the  order  of  the  goals  in  a 
clause  and  the  order  of  the  clauses  themselves  are  both  irrelevant  to  the  declarative 
interpretation.  However,  these  orderings  are  generally  significant  in  Prolog,  as  they  con- 
stitute the  main  control  information. 

When  the  Prolog  system  is  executing  a procedure  call,  the  clause  ordering  determines 
the  order  in  which  the  different  entry  points  of  the  procedure  are  tried.  The  goal  order- 
ing fixes  the  order  in  which  the  procedure  calls  in  a clause  are  executed.  The  ’produc- 
tive’ effect  of  a Prolog  computation  arises  from  the  process  of  ’matching’  a procedure 
call  a'gainst  a procedure  entry  point. 

3.4.2  Step  by  Step  Description  of  the  Synthesis  Process.  In  this  section  we  describe  by 
means  of  an  example  how  ERL  template  representations  drive  event  record  synthesis. 
Consider  the  following  example: 

(1)  THIS  AIRCRAFT  ROUTINELY  PRECEDES  UAF  B-75  DEPLOYMENTS  TO  MAURITIUS. 

As  pointed  out  previously,  one  of  the  basic  principles  underlying  our  approach  to  the 
content  analysis  of  narrative  text  is  that  the  structural  descriptions  at  all  levels  of 
analysis  should  be  homogeneous.  Sentence  (7)  above  was  chosen  precisely  because  it 
allows  us  to  show  how  the  same  formalism  lends  itself  naturally  to  the  description  of 
structures  and  processes  at  several  levels  of  grammatical  description  thus  providing  a 
homogeneous  approach  to  the  interpretation  of  the  syntactic  structures  output  by  the 
ATN.  Specifically,  the  levels  of  grammatical  description  involved  in  the  analysis  of  (7) 
are:- 

• syntactic  normalization; 

• the  description  of  objects  (aircraft); 

• the  description  of  an  atomic  event  (’deployments’); 

• the  description  of  a text-level  relation  ('precede'). 

Sentence  (1)  states  that  certain  deployments  are  routinely  preceded  by  a certain  flight. 
Notice  that  syntactically,  (7)  is  a simple  sentence  of  the  form  Subject,  Verb,  Object. 
Conceptually,  however,  it  is  a complex  structure  in  which  the  main  verb  ’precede’ 
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functions  as  a text-level  relation  locating  two  events  on  the  time  line.  The  two  events 
are  linguistically  encoded  as  the  subject  and  the  object  of  the  verb  ’precede’.  Note  that 
the  subject  is  ’this  aircraft’  which,  although  syntactically  a simple  noun  phrase  describ- 
ing an  object,  is  understood  as  'the  flight  of  this  aircraft’,  i.e.,  it  is  understood  as  the 
description  of  an  event.  This  is  information  which  does  not  reside  in  the  actual  text,  and 
which  will  eventually  be  supplied  by  an  inferential  component  utilizing  extralinauistic 
knowledge  stored  in  the  system.  The  current  version  of  ERL  lacks  the  necessary 
Inferential  mechanisms  which  would  supply  this  information.  ’This  aircraft’,  therefore,  is 
Interpreted  as  the  description  of  an  object.  As  mentioned  above,  ’precede’  relates  two 
events  on  the  time  axis.  ’Precede',  then,  is  a relation  which  has  two  arguments:  a 
’predecessor’  and  a 'successor'.  As  indicated  above,  the  first  argument  of  ’precede’  — 
the  ’predecessor’--  will  be  an  aircraft  description.  The  second  argument  of  ’precede' — 
the  'successor'  — will  be  the  interpretation  of  the  syntactic  object  of  the  sentence. 
ERL  utilizes  a normalization  rule  to  transform  the  latter  into  a sentential  structure  which 
Is  then  further  interpreted  by  rules  of  semantic  interpretation,  and  transformed  into  an 
event  record  of  type  ’deploy’. 

A diagrammatic  representation  of  the  final  output  of  the  event  record  synthesizerjis 
given  in  Figure  1,  which  is  read  as  follows:- 

The  record  is  of  type  ’precede’.  The  ’predecessor’  describes  an  object  of  type  ’aircraft’, 
while  the  ’successor’  describes  an  event  of  type  ’deploy’.  The  objects  being  deployed 
are  UAF  8- 75s,  and  the  destination  of  these  aircraft  is  Mauritius. 


Precede  

Modifier:  ROUTINELY  lAircraft  I 

Predecessor:  > I Equipment:  THIS  AIRCRAFT  I 

I I 


IDeploy  I 

lObject: — >|Aircraft  I I 

I I Equipment:  B-75  I I 

Successor:  >|  (Service:  UAF  j I 

I I I ! 

IDestination:  TO  MAURITIUS  I 

I I 


Figure  1.  Content  Representation  of  "THIS  AIRCRAFT  ROUTINELY 
PRECEOES  UAF  B-75  DEPLOYMENTS  TO  MAURITIUS". 

3.4.2. 7 The  Initiation  ot  the  Synthesis  Process.  In  this  section  we  give  a detailed  step 
by  step  description  of  the  event  record  synthesis  process  as  executed  by  MATRFS  II. 
As  explained  in  a previous  section,  the  ERL  semantic  interpretation  rules  (clauses)  are 
used  top-down,  one  at  a time.  Goals  in  a clause  are  executed  from  left  to  right.  If  there 
are  alternative  clauses  at  any  point,  backtracking  will  return  to  them.  To  sec  how  parse 
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trees  are  Interpreted  by  ERL.  consider  (2),  which  is  the  parse  tree  of  sentence  (1)  - 

(2)  s(np(dp(0,  THIS,0),[J,  nnode(AIRCRAFT,0),[]  ), 
vg(l  ROUTINELY], [ ].0, PRECEDES), 
np(0,[  nnode(UAF.O),nnodo(B-  76,0)], 
nnode(DEPl  OYMENTS.O), 

[pp((  l,TO,np(0.[ ].nnode(MAllRITIUS,0),[  ]))]). 

o.lD. 

For  simplicity  ot  exposition  we  will  henceforth  refer  to  structure  (?)  as  'Tree_ln\ 

The  synthesis  process  involves  the  execution  ot  the  system-generated  goal  (3): 

(3)  bulld_ER  (’Tree  In’ ,ER). 

'build  ER’  clauses  have  two  arguments:  the  input  structure  ’Troe_Jn’,  which  in  our  case 
is  the  structure  given  in  (2),  and  an  output  structure  I H,  which  is  the  content  represen- 
tation of  'Tree_in'.  j 

3.4.2.?  Activation  ot  Template.  Since  'lree_in’  in  our  example  is  a sentential  structure, 
goal  (3)  unifies  with  the  head  of  the  first  clause  of  the  ’bulld__ER’  procedure  (A). 

(4)  buitd_ER  (s(Subj,Vbgr,Obj,Compl,Vmods),ER):- 

find„t  name(Vbgr.Nanie), 
construct(Name,'Tree_in’  .ER). 

This  results  in  the  following  instantiations: 

(5)  Sub  j = np(dp(O.IHIS.O).[].nnode(AIRCRAt  T,0).[]): 

Vbgr  = vg([ROUT  INI  l Y],|  J.O.PRECEDf  S); 

Obj  = np(0,[nnode(UAI  ,0),nnode(B-75,0)], 
nnode(Df  Pl.OYMI  NTS.O). 

[pp([  ],TO,np(0,[ ].nnodo(MAlJRITUJS,0), []))]); 

Compl  = 0; 

Vtnods  = []. 

The  body  of  the  matching  clause  Instance  (4)  also  gives  rise  to  the  two  new  subgoals 

(6)  and  ( 7): 

(0)  find  t name(vg([ROl)l  INEEY ),[  ],0,PRE£EDFS),Name). 

(7)  construct(Name, 

s(np(dp(0.THIS.0).[  ],nnodo(AIRCRAf  T,0).f  )). 
vgtfROUTTNEI  Y]  ,|  J.O.PRFCEDf  S). 
np(0.J  nnode(UAf  ,0),nnodo(B- 7b, 0)]. 
nnode(DEPl  OYMI  N1S.0). 

[pp([  ],T 0.np(0,[  |,nnode( MAURI  I IUS,0),f  1))]). 

0,[]),ER). 

lhe  first  task  is  to  identity  the  template  required  for  the  Interpretation  of  (2)  this  Is 
achieved  by  executing  goal  (6)  listed  above 

Goal  (6)  matches  the  head  of  the  first  clause  of  the  'find_  t name'  procedure  (see  H).  It 
produces  the  instantiations  in  (0),  and  yields  the  new  goal  (10):- 
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(8)  find_t_name(vg(_,_,_,W),Y):- 

find_feat(W,L,Y). 

(9)  W =’precedes’  ; y = Name 

(10)  find_feat  (’precedes’,  [list  of  event  template  names],  Name). 

Goal  (10)  in  turn  unifies  with  the  head  of  the  ’find_feat’  clause  (11) 

(11)  find_feat  (W,L,Y):- 

mem  (Y,L), 
feat  (W,Y). 

This  creates  the  following  instantiation  (12):- 

(12)  find_feat  (’precedes',  [list  of  event  template  names],  Name):- 

mem(Name,[list  of  event  template  names]), 
feat(’precedes’,  Name). 

The  execution  of  the  subgoals  of  (12)  result  in  the  instantiations  (13):- 

(13.1)  Name  = ’Precede’ , and 

(13.2)  construct(’precede’,  Tree-in’,  ER). 

where  (13.2)  is  still  only  a partial  instantiation  of  (7). 

Goal  (6)  is  now  fully  instantiated,  i.e.,  the  name  of  the  template  sought  was  found  to  be 
’precede'. The  system  now  proceedes  to  execute  second  goal  set  up  by  executing  (3), 
namely  goal  (7),  now  instantiated  to  (13.2).  Executing  this  goal  results  in  the  instantia- 
tion of  the  two  arguments  of  ’precede’,  namely,  El  and  E2. 

3.4. 2.3  Instantiating  the  Arguments  of  'PRECEDE.'  The  reader  is  reminded  that  the  verb 
’precede’  Is  a two-place  predicate  whose  interpretation  in  the  environment  of  a subject 
El  and  an  object  E2  is  ’before(E1  ,E2)’.  The  ’construct’  procedure  for  ’precede’  seeks  to 
find  fillers  for  the  two  arguments  El  and  E2.  To  achieve  this  result,  goal  (13.2)  unifies 
with  the  head  of  the  ’contsruct’  clause  for  ’precede’  (14),  and  sets  up  the  two  subgoals 
(14.1)  and  (14.2):- 

(14)  construct  ('precede',  s(Subj,_,Obj,_,_),  [E1,E2]):- 

(14.1)  build_ER(Subj,E1 ), 

(14.2)  build_ER(Obj,  E2). 

where,  according  to  (5), 

Subj=np  (dp(0,THIS,0),[],nnode(AIRCRAFT,0),[]); 
Obj=np(0,[nnode(UAF,0),nnode(B-75,0)], 
nnode(DEPL0YMENTS,0), 

[PP([]|T0, np(0, [], nnode(MAURITI  US, 0), []))]). 

The  next  step  is  to  execute  goals  (14.1)  and  (14.2). 

3 .4.2.4  Interpreting  the  Syntactic  Subject.  The  partially  instantiated  goal  (14.1)  is 
shown  in  (15):- 

(15)  build_ER(np(dp(0,THIS,0),[],nnode(AIRCRAFT),0),[]),ER). 

Since  the  first  argument  of  (15)  is  a nounphrase,  it  will  unify  with  the  head  of  the 
second  ’build_ER’  clause  (16):- 
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(16)  build_ER(np(Det,L1,N(W,_).L2),ER):- 

feat(W,'NOM7’), 

change(np(Oet,l  1 ,N(W,_  ).l  2),1  1 ), 
build_ER(ri,ER). 

However,  the  first  goal  of  clause  (16)  requires  that  the  headnoun  have  the  feature 
’NOMZ’.  This  is  not  the  case  in  our  example,  so  that  the  first  goat  fails.  The  system  now 
backtracks,  i.e.,  it  rejects  the  most  recently  activated  clause  (16)  undoing  any  substitu- 
tions made  by  the  match  with  the  head  of  the  clause.  Next,  it  reconsiders  the  original 
goal  (15)  which  activated  the  rejected  clause,  and  tries  to  find  a subsequent  clause 
which  also  matches  the  goal.  As  a result,  goal  (15)  now  unifies  with  the  head  of  the 
third  ’build_ER’  clause  (17):- 

(17)  build_ER(np(0et,L1  ,Noun,L2),ER):- 

(1  7.1 ) find.  _t_name(Noun,  Name), 

( 1 7.2)  construct(Name,np(Det,L1  ,Noun,L2),ER). 

This  results  in  the  following  instantiations:- 

(18)  Det  = dp(0,THIS,0); 

LI  = []; 

Noun  = nnode(  AIRCRAFT  ,0); 

12  = []; 

El =ER. 

The  first  goal  of  (17)  unifies  with  (19):- 

(19)  find__t_  name(nrlode(W,0),Y):- 

find_ feat(W, ['aircraft’,  'OTG',  etc],  Y). 

The  procedure  here  is  similar  to  that  described  earlier.  As  a result  of  the  unification  pro- 
cess, and  of  executing  (19),  we  have  the  following  instantiation:- 

W = 'AIRCRAFT’ 

Y = Name  = ’aircraft’. 

Clause  (17.1)  Is  now  fully  Instantiated  — the  template  sought  has  been  found  to  be  the 
’aircraft’  template.  The  system  proceedes  to  the  execution  of  goal  (17.2). 

Goal  (1  7.2)  is  now  partially  instantiated  to  (20):- 

(20)  oonstruct(’aircraft’,  np(0,THIS,0),[], 

nnode(AIRCRAFT,0),[]),ER). 

Goal  (20)  activates  the  ’construct’  procedure  for  ’aircraft’,  which  fills  the  ’equipment’ 
slot  with  ’this  aircraft',  and  loaves  all  other  slots  empty.  The  result  of  executing  (20) 
l9:- 

+ + 

I aircraft  I 

El  = | equipments  THIS  AIRCRAFT  | 

I I 


l 
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3.4.2. 5 Interpreting  the  Syntactic  Object.  Rather  than  describing  the  process  of  syn- 
thesizing a record  for  ’this  aircraft’  in  detail,  we  will  return  to  the  second  goal  of  the 
’construct’  clause  for  ’precede’,  namely,  to  (14.2),  which  is  now  partly  instantiated  to 

(21):- 

(21)  buiid_ER(np(0,[nnode(UAF,0),  nnode(B-75,0)], 

nnode(DEPl  OYMENTS.O), 

[pp(t]JO,np(0,[],nnode(MAURITIUS,0),[]))]).ER). 

The  first  argument  of  this  clause  is  the  nominalized  sentence  ’UAF  B-75  DEPLOYMENTS 
TO  MAURITIUS’. Accordingly,  clause  (21)  will  unify  with  the  head  of  the  second  ’build_ER* 
clause,  namely  (16),  reproduced  here  as  (22)  in  Its  partly  instantiated  form,  complete 
with  its  subgoals  (22.1),  (22.2),  and  (22.3):- 

(22)  build_ER(np(0,[nnode(UAF,0),nnode(B-75,0)], 

nnode(DEPl  OYMENTS.O), 

[PP([  ], TO, np(0,[], nnode(MAURITIUS.O), []))]), ER):- 

(22.1)  feat(DEPLOYMENTS,  ’NOMZ’), 

(22.2)  change(np(0,[nnode(UAF,0),nnode(B-75,0)], 

nnode(DEPL0YMENTS,0), 

[PP([]*TO,np(0,[],nnode(MAURITIUS,0), []))]), T 1 ), 

(22.3)  build_ER(T1  ,ER). 

Goal  (22.1)  succeeds,  and  the  system  activates  the  ’change’  procedure.  Goal  (22.2) 
unifies  with  (23)  below,  which  restructures  the  input  nounphrase  into  a sentential 
structure:- 

(23)  change(np(Det,[L  1 ,XJ,nnode(W,0),L2), 

s(np(Det,L1,nnode(X,0),[],),vg(_^_,0,W),0,0,L2)). 

Upon  unification  with  (22.2),  (23)  becomes  Instantiated  to  (24): 

(24)  change(np(0,[nnode(UAF,0),nnode(B-75,0)], 

nnode(DEPLOYMENTS.O), 

[pp([],T0,np(0,[],nnode(MAURITIUS,0), []))]), 

s(np(0,[nnode(UAF,0)], 
nnode(B-75,0),[]), 
vfldJ.n.O, DEPLOYMENTS), 

O, 

0, 

fpp([].TO,np(0,[],nnode(MAURITIUS,0),  []))])). 

T 1 Is  instantiated  to  the  second  argument  of  (24).  The  system  now  proceedes  to  exe- 
cute goal  (22.3)  reproduced  here  in  its  instantiated  form  (25):- 

(26)  build„ER(s(np(0,[nnode(UAF,0)], 
nnode(B-76,0),[], 

V9([].[].0,OEPLOYMENTS), 

0,0, 

[pp([  ],TO.np(0,[  ], nnode(MAURI  TIUS.O), []))]), ER). 

Execution  of  the  ’built^ER’  goal  (25)  eventually  results  In  the  activation  of  the  'con- 
struct' clause  for  ’deploy’  (26):- 
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(26)  construcU’deploy’  ,IT,  [01,01,12]):- 
objectl  (IT,  Ol ), 
destination!  (IT,  01), 
time2  (IT,  T2). 

with  'IT'  instantiated  to  the  first  argument  of  (26).  The  goal  ’objectl’  activates  the 
'object V procedure  (28):- 

(28)  objectl  (s(Subj,__ ,_,_),  Slot):- 
test_nhead(Subj,  'acraft'), 
construct  'aircraft’,  Subj,  Slot). 

The  result  is  the  instantiation:- 

Subj  = np(0,[nnode(UAF,0)],nnode(B-75,0),[]). 

and  'Slot'  gets  linked  to  'Ol'. 

The  goal  ’test_nhead’  determines  whether  the  headnoun(W)  of  a noun  phrase  'np'  has 
the  feature  Feature.  It  unifies  with  the  clause  for  ’test_nhead’  (30),  and  results  in  the 
Instantiations  (31):- 

(30)  test_nhead  (np  (_,_,nnode(W,_)),Feature 

(31)  W=  B-75’;  Feature  = 'acraft' 

Goal  (30)  succeeds,  and  the  system  begins  executing  the  second  goal  of  (28)  namely 
(33):- 

(33)  construct  (’aircraft’,  Subj.ER). 

The  second  goal  of  (26)  activates  the  'destination'  procedure  (35)  and  returns  D1  = 'To 
Mauritius' 

(35)  destination  (s(_ Vmods),  Slot):- 

fill_slot(Vmods,  ['nil',  'to' ],  Toe’,  Slot). 

The  third  goal  of  (26)  activates  the  ’time2’  procedure  (37),  which  returns  T2  = 'nil'. 

(37)  time2  (s(_,_._,_ .Vmods).  Slot):- 

fill_slot(  Vmods,  ['at',  'between',  'by',  'during'], 

'tyme'.  Slot). 

time2  (s(_,_,_,_ .Vmods),  Slot):- 
fill_slot(  Vmods,  'tyme',  Slot). 

tlme2  (_  ,nil). 

This  completes  the  execution  of  goal  (26).  As  a result,  the  second  output  element  (t2) 
of  the  'construct'  procedure  for  'precede'  Is  Instantiated  to  an  event  record  of  type 
'deploy',  l.e.. 


! 


i 

i 


1-34 


E2 


deploy 


object=  I aircraft  I 

I equipments  B-75  I 

I services  IMF  | 

I I 

destinations  TO  MAURITIUS 


3.4.2. 6 Output  of  Event  Record  Synthesis  Process.  The  complete  diagrammatic 
representation  of  the  content  of  (1)  is  given  in  figure  1,  which  shows  the  relation 
between  El , E2,  and  its  subparts. 

The  text-level  semantic  interpretation  rule  SI  of  the  Metres  II  System  now  interprets 
the  results  as  follows:- 

S1.  [’precede*,  ’Tree_in’,  [El,  E2]]  =>  before(E1,  E2) 
meaning  "The  content  of  El  happens  before  the  content  of  E2". 

This  completes  our  account  of  the  interpretation  of  sentence  (1). 
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4.0  The  MATRES  II  System 

4.1  Introduction 


MATRES  II  is  the  result  of  the  second  cycle  In  the  development  of  a system  with  full 
capabilities  for  deriving  formatted  records  from  the  narrative  text  of  intelligence  mes- 
sages. It  represents  a considerable  advance  on  MATRES  I,  which  provided  only  a rudi- 
mentary capability  for  testing  algorithms  for  narrative  text  analysis. 

The  primary  subject  domain  of  MATRES  II  is  that  of  air  activities.  While  in  a fully 
developed  system  the  unit  of  analysis  would  be  the  entire  message,  the  scope  of  the 
current  system  Is  still  limited  to  the  analysis  of  single  sentences. 

The  MATRES  I parser  has  undergone  considerable  refinement  and  expansion  and 
currently  accepts  a much  wider  range  of  syntactic  constructions  than  was  previously 
achieved.  The  definition  of  the  input  language  accepted  by  the  system  is  embodied  in  a 
transition  network  grammar  model  based  upon  Woods  (1970,  1973).  A detailed  description 
of  the  syntactic  constructions  accepted  by  the  current  system  is  given  in  subsection 
4.3. 

Since  the  transition  network  parsing  methodology  is  by  now  quite  well  known,  little  will 
be  said  about  the  parser  itself.  Part  II  of  this  report,  however,  does  include  detailed 
documentation  of  our  particular  implementation.  In  this  section,  we  focus  mainly  upon  the 
parsing  strategy  adopted  in  MATRES  II,  including  the  augmented  transition  nets  used  by 
the  system.  This  is  the  subject  of  subsection  4.4. 

In  the  current  system  English  language  words  are  entered  into  a linguistic  dictionary, 
while  strings  with  fixed  patterns  are  recognized  at  the  input  stage  by  a finite  state 
automaton  (FSA)  designed  especially  for  this  purpose 

The  major  feature  of  MATRES  II  Is  its  capability  for  semantic  analysis.  This  is  achieved 
by  means  of  the  Event  Representation  language,  which  is  a language  specially 
developed  for  mapping  the  syntactic  structures  produced  by  the  parser  Into  template- 
derived  content  representations.  As  discussed  in  Section  3,  the  basic  data  structure  of 
the  Event  Representation  l anguage  Is  the  template.  Section  4.6  describes  the  template 
Inventory  so  far  developed  for  the  aircraft  domain,  and  presents  the  methodology  for  the 
selection  of  the  descriptors  to  be  included  in  templates  of  a particular  subject  domain. 

The  next  section  provides  a brief  functional  description  of  MATRES  II. 

4.2  MATRES  II  --  Functional  Description 

An  overview  of  the  MATRES  II  system  organization  and  data  flow  is  shown  in  Figure  4-1. 
The  main  system  components  are:  the  l exical  Unit  Recognizer,  the  ATN  parser,  and  the 
ERL  "machine".  The  direction  of  the  arrows  in  the  Figure  indicate  the  general  flow  of 
information  as  a sentence  is  processed  through  the  system.  The  main  stages  of  event 
record  generation  are  shown  across  the  center  of  the  Figure.  The  analysis  begins  when 
an  input  sentence  is  received  by  the  Lexical  Unit  Recognizer,  which  uses  a stored  dic- 
tionary and  the  FSA  Recognizer  to  transform  the  individual  words  of  an  input  sentence 
Into  a string  of  lexical  units.  First,  a dictionary  look-up  process  replaces  words  and 
phrases  In  the  sentence  with  corresponding  lexical  entries.  Strings  which  have  no 
entries  In  the  dictionary  are  passed  to  the  FSA  Recognizer,  which  attempts  to  identity 
them  as  one  of  several  fixed-pattern  categories.  The  output  of  this  stage  is  a string  of 
lexical  units  containing  syntactic  and  semantic  information  for  use  by  the  parser,  and 
later  by  the  ERL  Interpretive  routines. 
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Next,  the  string  is  input  to  the  parser,  which  analyzes  it  according  to  the  sublanguage 
grammar  stored  in  the  system,  and  produces  a parse  tree  showing  the  constituent  struc- 
tures of  the  input  string  and  their  hierarchical  relationships. 

The  parse  tree  in  turn  is  input  to  the  FRL  "machine",  which  uses  the  pattern  matching 
process  ("unification  mechanism")  of  the  Event  Representation  l anguage  to  produce  a 
set  of  one  or  more  event  records  representing  the  information  content  of  the  input  sen- 
tence. 

Feeding  into  this  are  the  various  analysis  components,  each  compiled  from  a source  text 
in  a language  appropriate  to  the  component.  The  base  language  for  all  the  programs  -- 
except  the  ERL  machine  --  is  Forth;  the  respective  compilers  are  written  in  FORTH  and 
the  compiled  form  of  the  various  components  is  the  threaded  code  characteristic  of 
Forth.  The  ERL  compiler  is  coded  in  SPITBOL,  a dialect  of  SNOBOl  4,  which  was  chosen 
because  of  its  excellent  facilities  for  compiler  writing. 

The  following  are  two  examples  showing  the  internal  processing  of  sentences.  The  first 
example  shows  the  parse  tree  followed  by  the  event  record  produced  by  the  ERL 
machine;  the  second  example  only  shows  the  input  sentence  and  the  MATRES  II  output. 

Example  1 

*>>  TWO  UGANDAN  ACFT  FROM  REGIMENT  A313  AT  ENTEBBE  DEPLOYED  TO  GULU 
*AT  0200Z  ON  21  FEBRUARY. 

PARSE  OUTPUT: 

LIST  OF: 

I NODE:  IIS 
I I LIST  OF: 

I I I NODE:  2IPP 
I I I I NODE:  4 1 DATE 
I II  I I <<NIL>> 

I I I I I 392..  FEBRUARY 

I I I I I LIST  OF: 

I I I I I I 372..  21 

I I I I I END  LIST 

I I I I END  NODE 
I I I I 352..  ON 
I I I I LIST  OF: 

I I I I END  LIST 
I I I END  NODE 
I I I NODE:  2IPP 
I II  I LIST  OF: 

I I I I I 332..  0200Z 

I I I I END  LIST 
I I I I 312..  AT 
I I I I LIST  OF: 

I I I I END  LIST 

II  I END  NODE 

I I I NODE:  2IPP 
I I I I NODE:  21 NP 

I I I I I LIST  OF: 

I I I I I END  LIST 

I I II  I NODE:  5 INNOD 
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Mil  <<NIL>> 

I I I I 292. . GULU 
I I I END  NODE 
I I I LIST  OF: 

I I I END  LIST 
I I I <<NIL>> 

I I END  NODE 
I I 272.  .TO 
I I LIST  OF: 

I I END  LIST 
I END  NODE 
END  LIST 
< < N I L > > 

<<NIL>> 

NODE:  2 1 VG 
I 232..  DEPLOYED 
I <<NIL>> 

I LIST  OF: 

I END  LIST 
I LIST  OF: 

I END  LIST 
END  NODE 
NODE:  2 INP 
I LIST  OF: 

I I NODE:  2 1 PP 
I I I NODE:  2 INP 

I I I I LIST  OF: 

II  I I END  LIST 

I I I I NODE:  5 INNOD 
I I I I I <<NIL>> 

I I I I I 212..  ENTEBBE 
I I I I END  NODE 
I I I I LIST  OF: 

I I I I END  LIST 
I I I I <<NIL>> 

I I I END  NODE 
I I I 192..  AT 
I I I LIST  OF: 

I I I END  LIST 
I I END  NODE 
I I NODE:  2 1 PP 

I I I NODE:  2 INP 

II  I I LIST  OF: 

I I II  END  LIST 
I I I I NODE:  5 INNOD 

I I I I I < <NI L>> 

II  I I I 172..A313 
I I I I END  NODE 

I I I I LIST  OF: 

I I I I I NODE:  5 INNOD 
I I I I I I < <NI L>  > 


1 

1 

Mill  182..  REGIMENT 

1 

1 

1 1 1 1 END  NODE 

1 

1 

1 1 1 END  LIST 

1 

1 

1 1 1 <<NIL>> 

1 

1 

1 1 END  NODE 

1 

1 

1 1 152..  FROM 

I 

1 

1 1 LIST  OF: 

1 

1 

1 l END  LIST 

1 

1 

1 END  NODE 

1 

1 

END  LIST 

1 

1 

NODE:  S INNOD 

1 

1 

1 <<NIL>> 

1 

1 

I 132.  .ACFT 

1 

1 

END  NODE 

1 

1 

LIST  OF: 

1 

1 

1 112..  UGANDAN 

1 

1 

END  LIST 

1 

1 

NODE:  21  DP 

1 

1 

1 LIST  OF: 

1 

1 

1 1 92..  TWO 

1 

1 

1 END  LIST 

1 

1 

1 <<NIL>> 

1 

1 

1 < <NIL>  > 

1 

1 

END  NODE 

1 

END  NODE 

END 

NODE 

END  LIST 


Event:  DEPLOY 
Object: 

. . . Equipment*  UGANDAN  ACFT 

. . . Nationality*  UGANDAN 

...Subordination*  FROM  REGIMENT  A313 

. . . Stagingbase*  AT  ENTEBBE 

. . . Number*  TWO 

Destination*  TO  GULU 

Time*  AT  0200Z 

Date*  ON  21  FEBRUARY 

EVENT  RECORD  COMPLETE. 


Example  2 


•PRTREE  OSET 

*>>  THE  TWO  ACFT  WERE  ENROUTE  TO  NAIROBI  ON  RECONNAISSANCE. 

Event:  ENROUTE 

Object: 

. . . Equipment*  ACFT 
...Number*  TWO 
Mission*  ON  RECONNAISSANCE 
Destination*  TO  NAIROBI 
EVENT  RECORD  COMPLETE. 
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4.3  Linguistic  Grammar  and  Lexicon  for  Aircraft  Domain 

4.3.1  The  Grammar.  In  this  section  we  give  an  informal  description  of  the  major  gram- 
matical constituents  which  are  recognized  by  the  MATRES  II  parser,  and  of  the  analyses 
which  are  given  them.  The  parser  itself  is  described  in  section  4.4 

4.3. 1.1  The  Declarative  Sentence.  A declarative  sentence  may  be  a simple  sentence,  as 
in  (1),  or  it  may  be  a simple  sentence  conjoined  by  a sentence  conjunction  with  another 
simple  sentence  (of  a special  type)  or  with  a noun  phrase,  as  in  (2)  and  (3). 

(1)  THE  AIRCRAFT  WERE  ENROUTE  HOMEBASE  AT  0200Z. 

(2)  THE  AIRCRAFT  WERE  ENROUTE  HOWIE  BASE  AT  0200Z  AFTER 
CONDUCTING  A RECONNAISSANCE  MISSION  OVER  THE  RED  SEA. 

(3)  THE  AIRCRAFT  WERE  ENROUTE  HOMEBASE  AT  0200Z  AFTER 
A RECONNAISSANCE  MISSION  OVER  THE  RED  SEA. 

The  MATRES  II  grammar  analyzes  a declarative  sentence  as  a list  having  as  its  first  ele- 
ment a simple  sentence,  which  may  be  followed  optionally  by  a sentence  conjunction  and 
either  another  simple  sentence  or  a noun  phrase. 

4.3. 1.2  The  Simple  Sentence.  A simple  sentence  has  a noun  phrase  subject  followed  by 
a verb  group,  optionally  followed  by  a direct  object,  a complement,  and  one  or  more 
post-verb  modifiers. 

The  grammar  analyzes  a simple  sentence  as  a five-branched  node  structure.  The  first 
branch  points  to  the  subject,  the  second  branch  to  the  verb  group,  the  third  to  the 
object,  the  fourth  to  a complement,  and  the  fifth  to  a list  of  adverbial  modifiers. 

4.3.1 .3  The  Noun  Phrase.  A noun  phrase  may  consist  of  a determiner  followed  by  a list 
of  pre-head  modifiers,  a head  noun,  and  a list  of  post-head  modifiers. 

A determiner  may  consist  simply  of  an  article  (eg.  ‘THE’),  a quantifier  (eg.  ‘ALL'),  or  a 
number  phrase  (eg.  ‘AS  MANY  AS  SIX’),  or  it  may  be  a complex  structure  involving  two  or 
three  of  these  constituents,  as  in  (4)  through  (7). 

(4)  ALL  THE  AIRCRAFT 

(5)  ALL  SIX  AIRCRAFT 

(6)  THE  SIX  AIRCRAFT 

(7)  ALL  OF  THE  SIX  AIRCRAFT 

Pre-head  modifiers  may  include  adjectives,  nouns,  past  participles,  and  present  partici- 
ples. In  the  aircraft  domain,  head  nouns  are  typically  preceded  by  several  modifiers 
referring  to  attributes  such  as  nationality,  subordination,  equipment  type,  etc.,  as  in  (8). 

(8)  RETURNING  UGANDAN  UBBC  SR-71  AIRCRAFT 

I 

Poosible  post-head  modifiers  are  relative  clauses,  reduced  relative  clauses,  and  prepo- 
sitional phrases.  An  example  of  each  is  given  in  (9)  through  (1 1),  respectively. 
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(9)  THE  AIRCRAFT  WHICH  WERE  STAGING  FROM  ENTEBBE 

(10)  THE  AIRCRAFT  STAGING  FROM  ENTEBBE 

(11)  THE  AIRCRAFT  FROM  ENTEBBE 

A noun  phrase  is  analyzed  as  a four-branched  node.  The  first  branch  points  to  a deter- 
miner (possibly  null,  as  in  (8)),  the  second  to  a list  of  pre-head  modifiers,  the  third  to  the 
head  noun,  and  the  fourth  to  a list  of  post-head  modifiers. 

As  a heuristic  device,  we  allow  only  simple  noun  phrases  (i.e.,  those  without  post-head 
modifiers)  to  occur  as  direct  objects  or  prepositional  objects.  The  reason  for  this  is 
best  illustrated  by  an  example.  In  (12),  we  wish  to  analyze  the  relative  clause  ‘WHICH 
CONDUCTED  OPERATIONS  OVER  THE  RED  SEA’  as  a post-head  modifier  of  ‘AIRCRAFT’ 
rather  than  ‘ENTEBBE’.  This  is  effected  by  requiring  that  ‘ENTEBBE’,  which  is  a preposi- 
tional object,  have  no  post-head  modifiers. 

(12)  THE  AIRCRAFT  FROM  ENTEBBE  WHICH  CONDUCTED  OPERATIONS 
OVER  THE  RED  SEA 

Likewise,  in  the  embedded  sentence,  by  requiring  that  the  object  of  ‘CONDUCTED’  be  a 
simple  noun  phrase,  we  achieve  the  desired  analysis  of  ‘OVER  THE  RED  SEA’  as  an 
adverbial  modifier,  rather  than  a post-head  modifier  of  ‘OPERATIONS’. 

4.3. 7.4  The  Verb  Group  The  verb  group  may  consist  of  an  auxiliary  followed  by  a verb, 
as  in  (13),  or  an  auxiliary  followed  by  a copula  followed  by  an  adjective,  as  in  (14). 

(13)  HAVE  BEEN  CONDUCTING 

(14)  HAVE  BEEN  ACTIVE 

In  (13)  the  auxiliary  is  ‘HAVE  BEEN’,  while  in  (14)  the  auxiliary  is  ‘HAVE’,  and  ‘BEEN’  is  the 
copula. 

Some  verbs  (eg.  ‘CONDUCT’,  ‘PENETRATE’)  must  be  followed  by  a direct  object  consti- 
tuent, which  is  another  noun  phrase.  Other  verbs  (eg.  ‘ARRIVE’)  never  have  a direct 
object,  while  for  others  (eg.  ‘OPERATE’)  the  object  is  optional. 

Adverbial  modifiers  include  prepositional  phrases  and  adverbs,  and  may  occur  before  vhe 
subject,  as  in  (15),  after  the  verb  (and  the  object,  if  there  is  one)  as  in  (16),  or  embed- 
ded within  the  verb  group,  as  is  the  case  with  ‘CURRENTLY’  in  (1  7). 

(15)  AT  0200Z  ON  22  FEBRUARY,  THE  AIRCRAFT  PENETRATED  ENEMY  AIRSPACE. 

(16)  THE  AIRCRAFT  FLEW  NORTH  OVER  THE  INDIAN  OCEAN. 

(1  7)  THE  AIRCRAFT  ARE  CURRENTLY  ACTIVE  OVER  THE  RED  SEA. 

4.3. 7.5  Adverbials.  Pertaining  to  adverbial  modifiers,  there  are  several  constructions 
which  are  peculiar  to  our  particular  message  domain.  Principle  among  these  are  time 
phrases  and  date  phrases,  which,  along  with  noun  phrases,  are  accepted  as  preposi- 
tional objects.  Some  examples  of  time  phrases  are  given  in  (18)  through  (20). 
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(18) 0200/ 


(19)  0200-0400/ 

(20)  0200/  10  0400/ 

Oati?  phrases  art?  analyzed  as  three  branched  nodes.  The  first  branch  points  to  the  day, 
the  second  to  the  month,  and  the  third  to  the  year  (the  third  is  often  null).  Some  exam- 
ples are  given  in  (21)  through  (23). 

(21 ) 22  FEBRUARY 

(22)  22  FEBRUARY  7 4 

(23)  TUL  2 2ND  I EBRUARY 

4.3. 7 ,d  Passive  Sentences.  A sentence  such  as  (24)  can  be  paraphrased  as  (25), 
where  the  logical  subject  becomes  the  grammatical  object,  and  the  logical  object 
becomes  the  grammatical  subject. 

(24)  DURING  THE  0200/  HOUR,  FOUR  AIRCRAI  T FROM  RGI  XB412 
CONDUCILO  COMMAND- AND-CON  I ROt  OPERATIONS. 

(25)  DURING  TUI  0200/  HOUR,  COMMAND-AND-CON  I ROt  OPERA  HONS 
WERE  CONDUCTED  BY  i OUR  AIRCRAF  I FROM  RGI  XB4  1 2. 

The  MATRES  II  grammar  reverses  the  passive  transformation,  so  that  the  analyses  of 
(24)  and  (25)  are  identical,  with  ‘FOUR  AIRCRAFT  t ROM  RGT  XB4I2'  as  the  subject  and 
COMMAND-AND-CON  1 HOI  OPERATIONS’  as  the  direct  object. 

4.3.2  i he  Lexicon.  I he  MAIRIS  II  lexicon  is  designed  to  support  the  grammatical 
analysis  procedure.  It  consists  of  two  parts: 

(i)  a collection  of  lexical  entries  in  the  form  of  static 
declarations  of  lexica!  items  and  their  attributes,  and 

(it)  a listing  of  the  features  or  attributes  employed  by  the 
system. 

The  attributes  fall  into  several  classes.  Examples  of  each  are  given  below. 

(i)  Major  Grammatical  Category  Specifications. 

ADVB  (adverb) 

ADJ  (adjective) 

ART  (article) 

NUM  (number) 

N (noun) 

(ii)  Lexical  Features: 

DIR  (directional) 

LOC  (locational) 

SUBNIJM  (subordination  number) 

TENSED  (marks  tensed  verbs) 
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(lii)  Event  Category  Features: 


ARRIVl 
CONIINIII 
Dt PARI 
DEPLOY 


A portion  of  the  lexicon  is  given  in  figure  4-2,  and  a complete  listing  is  given  in  Appendix 

C. 


::  FLEET  | N SG  ] 

::  FLLW  [ VR  IRANS  11  NSLD  DIR  FLIGHT  ] 
::  LI  IGH1  l N SG  NOMZ  ] 

::  El  IGHTS  [ N • NOMZ  ] 

::  FLOGGER  [ N N/,  '0  ACRAL T ] 

::  FODDE  R [ N NATO  AC  RAFT  ] 

::  LOl  I OWING  [ SCONJ  ] 

::  fOR  [ PREP  ] 

::  FOUR  | NUM  J 

::  FRESCO  [ N NATO  ACRAL  1 ] 

::  FROM  [ PREP  ] 

::  GENLRAI  [ ADJ  J 
GROUP  IN].; 


Figure  4-2.  Sample  Lexical  Entries 

4.4  The  MATRES  II  Parser 

4.4.?  General  Description.  The  MATRES  II  system  uses  an  augmented  transition  network 
(ATN)  parser  based  on  Woods  (1970,  1973).  The  general  features  of  ATN  parsers  have 
been  discussed  in  detail  in  previous  OSI  reports  (RADC-TR-75,  RADC-TR- 7 7- 1 94).  In 
this  section  wo  review  a low  of  these  features  with  particular  attention  to  their  imple- 
mentation in  the  MA1R1S  II  system. 

An  AIN  grammar  consists  of  a finite  sot  of  states  connected  by  labeled  directed  arcs. 
Associated  with  each  aic  is  a sot  (possibly  null)  of  conditions  and  actions.  The  arc 
represents  a transition  from  the  state  at  its  tail  to  the  state  at  its  head,  which  may  be 
made  if  the  appropriate  conditions  are  met.  When  such  a transition  is  made,  the  actions 
associated  with  that  arc  are  executed. 

In  addition  to  the  above  components,  there  is  also  a push-down  store  (to  be  explained 
below  in  connection  with  PSH  arcs)  and  a set  of  registers,  including  the  special  register 
*,  which  usually  contains  tire  current  input  symbol  of  the  string  being  parked. 

An  input  string  is  processed  from  left  to  right,  beginning  at  the  leftmost  symbol  of  the 
string  and  a designated  initial  state  As  transitions  are  made  through  the  net,  the  input 
string  is  advanced,  so  that  the  current  input  symbol  is  in  turn  the  first  symbol  of  the 
Input  string,  the  second,  and  so  on.  A sentence  is  accepted  when  a final  state,  an 
empty  push-down  store,  and  the  end  of  the  input  string  are  all  achieved  simultaneously. 
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At  this  point  the  reader  may  wish  to  refer  to  the  diagrams  of  the  AIN  grammar  given  in 
figures  4-3  through  4-23,  and  the  grammar  listing  given  in  Appendix  D. 

4.4. 1.1  Arc  types.  There  are  five  different  arc  types  in  the  MATRES  II  grammar  The 
operation  of  these  arcs  is  described  informally  in  what  follows.  For  a formal  definition  of 
the  MATRES  II  grammar  language,  see  part  II. 

A CAT  arc  may  be  taken  if  the  current  input  symbol  belongs  to  the  category  (or 
categories)  specified  by  the  arc  label  (and  if  the  condition  associated  with  that  arc  is 
satisfied).  For  example,  a transition  via  an  arc  labeled  ‘CAT  [ ADJ  ]'  may  be  made  only  if 
the  current  input  symbol  belongs  to  the  category  ADJ  (i.e.,  has  the  feature  ADJ).  When 
a transition  is  made  via  a CA1  arc,  the  input  string  is  advanced  to  the  next  symbol. 

Transition  via  a WRD  arc  is  permitted  just  when  the  current  input  symbol  is  identical  to 
the  word  specified  by  the  arc.  For  example,  an  arc  labeled  ‘WRD  " BY"’  may  be  taken 
only  if  the  current  input  symbol  is  ‘BY’.  The  input  string  is  then  advanced  to  the  next 
symbol. 

A TST  arc  may  be  taken  if  the  the  condition  associated  with  that  arc  is  satisfied.  Condi- 
tions are  described  in  more  detail  in  the  next  section,  but  an  example  should  suffice  to 
give  the  general  idea.  Transition  via  an  arc  labeled  ‘TST  * [ N ] * [ ADJ  ] OR’  is  permit- 
ted when  the  contents  of  the  register  * (the  current  input  symbol)  is  a member  of  either 
the  category  N or  the  category  ADJ.  The  input  string  is  advanced  to  the  next  symbol. 

A PSEI  arc  transfers  control  to  the  state  named  by  the  arc  label,  while  the  state  at  the 
head  of  the  arc  is  saved  on  the  push-down  store.  For  example,  the  arc  ':PSH  TO  NP/  => 
S/SUBJ  has  the  effect  of  transferring  control  to  state  NP/  and  placing  state  S/SUBJ 
on  top  of  the  push-down  store.  When  a POP  arc  is  taken,  control  is  transferred  to  the 
state  at  the  top  of  the  push-down  store,  and  that  state  is  removed  from  the  push-down 
store.  PSH  and  POP  arcs  do  not  advance  the  input  string. 

A JUMP  arc  permits  a transition  to  the  state  named  by  the  arc  label  without  advancing 
the  input  string.  For  example,  the  arc  ‘:JUMP  S/OBJ  ,,’  transfers  control  to  state  S/OBJ 
with  the  current  input  symbol  remaining  the  same. 

4.4.1 .2  Conditions.  A condition  may  be  used  to  test  the  contents  of  a register  for  a 
given  feature,  numerical  value,  or  lexical  item.  For  example,  the  condition  '*  [ RELPRO  ]’ 
is  satisfied  just  when  the  current  input  symbol  has  the  feature  RELPRO,  and  the  arc 
*:PSH  * [ RELPRO  ] I!  TO  R/  =>  POST  MODS/P  ,,'  may  be  taken  under  exactly  the  same 
circumstances.  The  condition  ‘PASSIVE  GETR  1 =’  is  satisfied  just  in  case  the  contents 
of  PASSIVF  is  1,  and  the  condition  '*  " BY"’  is  satisfied  just  when  the  current  input  sym- 
bol is  the  lexical  item  ‘BY’ 

Conditions  may  be  formed  by  combining  tests  of  the  sort  described  above  with  the 
Boolean  operators  ‘AND’  and  ‘OR’.  Tor  example,  the  condition  ‘PASSIVE  GL1R  1 = * " BY" 
AND’  is  satisfied  just  in  case  the  contents  of  PASSIVE  is  1 and  the  current  input  symbol 
is  ‘BY’. 

4.4. 1.3  Actions.  The  action  functors  ‘SETR’  and  ‘GETR’  are  used  for  filling  registers  and 
retrieving  the  contents  of  registers,  respectively.  For  example,  the  action  '*  PR{  PRG 
SETR’  stores  the  current  input  symbol  in  the  register  PREPRG. 

The  structure-building  functors  ‘ADDEIST’  and  'NODE'  are  used  to  build  lists  and  nodes, 
respectively,  lor  example,  the  action  ’*  SENT  ADDEIST'  takes  the  contents  of  the  regis- 
ter * and  adds  it  to  the  list  SI  Nl.  The  action  ’PRTPRG  Gl  TR  OBJ  GETR  PP  NODE’  builds  a 
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two-branched  node  labeled  ‘PP’,  the  first  branch  of  which  points  to  the  contents  of 
PREPRG  and  the  second  of  which  points  to  the  contents  of  OBJ.  Notice  that  the  functor 
’GETR’  is  used  to  retrieve  the  contents  of  the  registers. 

In  connection  with  PSH  and  POP  arcs  we  must  distinguish  between  "pre-actions"  and 
"post-actions"  A pre-action  on  a PSH  arc  is  executed  before  control  is  transferred  to 
the  state  named  on  the  arc  label,  while  a post-action  is  executed  when  control  is 
"popped"  to  the  state  named  at  the  head  of  the  PSH  arc.  For  example,  when  a transi- 
tion is  made  via  the  arc  ‘.PSH  PASSIVE  SENDR  TO  S/VG  * SEN1  ADDLIST  =>  DCL/S  the 
action  ‘PASSIVE  SENDR’  (to  tie  explained  below)  is  executed  before  computation  begins 
at  state  S/VG.  Hie  action  '*  SiNI  ADDLIS1’  is  executed  when  control  is  popped  to 
state  L)C1  /S.  It  should  be  mentioned  here  as  well  that  upon  returning  from  a "push",  the 
register  * contains  whatever  structure  is  named  by  the  preceding  POP  arc.  For 
instance,  if  in  the  example  given  above  control  had  been  popped  to  state  DCL/S  by  the 
arc  ’.POP  SUBJ  GETR  VP  GE1R  S NODE  then  * would  contain  a two-branched  node 
labeled  ‘S',  and  this  is  the  structure  which  would  added  to  the  list  SENT  by  the  post- 
action ‘*  SENT  ADDI  1ST’. 

The  functors  ‘SENDR’  and  ‘SENOL’  are  used  to  send  a value  to  a register  or  a list  at  a 
lower  level  of  computation  For  example,  when  a transition  via  the  arc  ‘:PSH  VMODS 
SENDL  TO  VM/  =>  S/S  ,,'  is  made,  computation  begins  at  state  VM/  with  the  list  VMODS 
containing  exac  tly  what  it  did  at  the  state  from  which  the  push  was  made  (normally  lists 
and  registers  are  empty  upon  entry  into  a lower  level  of  computation).  ‘SENDR’  and 
‘SLNDl’  are  used  only  as  pre-actions  on  PSH  arcs. 

The  functors  ‘Rf  TR‘  and  ‘RE1L’  are  used  only  as  post-actions  on  PSH  arcs.e  and  are 
complementary  to  'SI  NDR'  and  ‘SI  NDI  ' in  that  they  retrieve  register  and  list  values  from 
a lower  level  of  computation  at  the  time  of  a pop  from  that  level.  Consider,  tor  example, 
the  arc  VPSH  VMODS  SI  NDI  IO  VM/  VMODS  RE  Tt  =>  S/S  Upon  popping  to  state  S/S, 
VMODS  contains  whatever  it  contained  before  the  push  to  VM/,  in  addition  to  whatever 
was  added  to  it  at  the  level  ol  VM/ 

4.4.2  The  Parsing  Strategy  In  this  section  a series  of  examples  is  used  to  describe  the 
manner  in  which  certain  grammatical  constituents  are  processed  by  the  MAfRES  II  ATN 
parser.  The  following  notation  for  output  structures  is  employed  throughout:  List  ele- 
ments are  enclosed  in  square  brackets  and  separated  by  commas.  The  entities  pointed 
to  by  the  branches  of  a node  are  enclosed  in  parentheses  and  separated  by  commas, 
with  the  node  label  preceding  the  left  parenthesis.  Lexical  units  are  enclosed  in  single 
quotation  marks. 

4.4.2. 1 The  Declarative  Snntern  e.  The  transition  network  for  declaratives  (see  Figure 
4-3  and  Appendix  D)  accepts  sentences  consisting  of  a simple  sentence  followed 
optionally  by  a sentence  conjunction  and  either  another  simple  sentence  or  a noun 
phrase.  It  returns  a list  having  as  its  tirst  member  an  S (sentence)  node,  which  may  be 
followed  by  a sentence  con  junction  and  either  another  S node  or  an  NP  (noun  phrase) 
node,  lor  example,  , veil  t I ),  the  declarative  net  returns  the  structure  given  in  (?). 

(1)  Till  AIRCRAf  I WIRE  FNROUTf  HOME  BASF  ALTER 
CONDUCTING  OPE  RATIONS  OV1  R T HI  RED  SI  A. 

(2)  [S(THE  AIRCRAF  I WE  Rl  INROUTE  HOMI  BASE). 

‘AFTER’, 

S(CONDUCTING  OPE  RATIONS  OVE  R THE  RED  SEA)] 


]-  l(; 


(1)  is  parsed  by  the  declarative  net  as  follows: 

4.4.2. 1.1  State  DCL/.  At  state  DCL/  (the  initial  state  ot  the  ATN  parser)  arcs  1 and  2 
are  attempted,  and  both  fail.  The  condition  on  arc  1 requires  that  the  contents  of  the 
register  REl  F be  1,  which  is  the  case  only  when  a relative  clause  is  being  parsed.  Simi- 
larly, the  condition  on  arc  2 is  satisfied  just  when  a reduced  relative  clause  is  being 
parsed.  Arc  3 succeeds,  and  control  is  pushed  to  the  sentence  net  at  state  S/.  ‘THE 
AIRCRAFT  WFRE  ENROUTE  HOMFBASE’  is  recognized  as  a sentence,  and  an  S node  is 
returned  to  the  declarative  net  where  it  is  added  to  the  list  DCL.  Control  then  passes  to 
state  DCL/S  with  ‘AFTER’  as  the  current  input  symbol. 

4.4.2. 1 .2  State  DCL/S.  At  state  DCL/S,  arc  1 is  taken,  since  ‘AFTER’  has  the  feature 
SCONJ  (sentence  conjunction).  ‘AFTER’  is  added  to  DCL,  the  input  string  is  advanced  to 
‘CONDUCTING’,  and  control  is  transferred  to  state  DCL/CONJ. 

4. 4.2.1 .3  State  DCL/CONJ.  Arc  1 at  state  DCL/CONJ  succeeds,  since  ‘CONDUCTING' 
has  the  feature  PRESP  (present  participle).  Control  is  pushed  to  the  sentence  net  at 
state  S/SUBJ,  and  ‘CONDUCTING  OPERATIONS  OVER  THE  RED  SEA'  is  recognized  as  a sen- 
tence (i.e.,  one  with  a null  subject).  An  S node  is  returned  to  the  declarative  net  and 
added  to  the  list  DCL.  Control  then  passes  to  state  DCL/S  with  the  end-of-sentence 
marker  as  the  current  input  symbol. 

4.4.2. 1 .4  State  DCL/ DCL.  This  time  arc  1 at  state  DCL/S  fails,  so  arc  2,  a jump  to 
DCL/DCL,  is  taken.  At  state  DCL/DCL  the  list  DCL,  which  has  the  form  given  in  (2),  is 
popped. 

To  take  another  example  of  a slightly  different  form,  consider  (3). 

(3)  THE  AIRCRAFT  WERE  ENROUTE  HOMFBASE 
AFTER  OPERATIONS  OVER  THE  RED  SEA. 

In  parsing  (3),  state  DCL/CONJ  is  reached  with  ‘OPERATIONS'  as  the  current  input  sym- 
bol. This  time  arc  1 at  DCL/CONJ  fails,  since  ‘OPERATIONS'  is  not  a present  participle, 
and  arc  2,  a push  to  the  noun  phrase  net,  is  taken.  ‘OPERATIONS  OVER  THE  RED  SEA'  is 
recognized  as  a noun  phrase,  and  an  NP  node  is  returned  to  the  declarative  net  and 
added  to  DCL.  The  list  popped  at  state  DCL/DCL  will  have  the  form  given  in  (4). 

(4)  [S(THE  AIRCRAFT  WERE  ENROUTE  HOMEBASE), 

‘AFTER’, 

NP(OPERAT!ONS  OVER  THE  RED  SEA)] 

4.4. 2. 2 The  Simple  Sentence.  The  sentence  grammar  (see  Figure  4-4  and  Appendix  D) 
accepts  sentences  composed  of  subject,  verb  group,  direct  object,  complement,  and 
various  adverbial  post  modifiers.  It  returns  a node  labeled  ‘S’  which  has  five  branches 
The  first  branch  points  to  the  logical  subject,  the  second  to  the  verb  group,  the  third  to 
the  direct  object,  the  fourth  to  the  complement  and  the  fifth  to  a list  of  "verb  modifiers". 
Given  (5),  for  example,  the  sentence  net  returns  the  structure  in  (6). 
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(5)  AT  0200Z  21  FEBRUARY  THREE  EGYPTIAN  AIRCRAFT  FROM  RGT 
XB4 1 2 WIRE  CONDUCTING  OPERATIONS  OVER  THE  RED  SEA. 

(6)  S(NP(THREE  EGYPTIAN  AIRCRAFT  FROM  RGT  XB412), 

VG(WERE  CONDUCTING), 

NP(OPERATIONS), 

0, 

[AT  0200Z,  21  FEBRUARY,  OVER  THE  RED  SEA]) 

(5)  is  parsed  by  the  sentence  net  as  follows: 

4.4. 2.2. 1 State  S/.  From  state  S/,  control  passes  via  arc  1 to  state  PP/,  the  initial 
state  of  the  prepositional  phrase  net.  ‘AT  0200Z’  is  recognized  as  a prepositional 
phrase,  and  a PP  node  is  returned  to  the  level  of  the  sentence  net,  where  it  is  added  to 
the  VMODS  list.  Control  returns  to  state  S/,  with  ‘21’  as  the  current  input  symbol. 

Back  at  state  .»/,  another  push  to  the  prepositional  phrase  net  is  attempted  via  arc  1, 
but  this  time  the  push  fails.  Arc  2,  a push  to  the  date  net,  is  attempted,  and  succeeds, 
with  ‘21  FEBRUARY’  being  recognized  as  a date.  An  appropriate  structure  is  returned  to 
the  sentence  net,  where  it  is  placed  in  the  VMODS  list.  Control  passes  again  to  state  S/ 
with  ‘THREE’  as  the  current  input  symbol. 

Arcs  1 and  2 at  state  S/  are  attempted  in  order  again,  and  both  fail.  Control  passes  via 
arc  3,  a jump  arc,  to  state  S/PP.  I he  current  input  symbol  is  still  ‘THREE’. 

4.4. 2.2. 2 State  S/PP.  At  state  S/PP,  a push  is  made  to  state  NP/,  the  initial  state  of 
the  noun  phrase  net.  'THREE  FGYPTIAN  AIRCRAFT  FROM  RGT  XB412'  is  recognized  as  a 
noun  phrase,  and  an  NP  node  is  built  and  returned  to  the  sentence  net,  where  it  is 
stored  in  the  register  SUBJ.  Control  then  passes  to  state  S/SUBJ  with  ‘WERE’  as  the 
current  input  symbol. 

4.4  2.3  State  S/SUBJ.  The  arc  at  state  S/SUBJ  is  a push  to  the  verb  group  net. 
'Wkhc  CONDUCTING’  is  recognized  as  the  verb  group,  and  a VG  node  is  returned  and 
stored  in  register  VGRG.  Additionally,  the  registers  PASSIVE  and  VHRG  are  raised  by  the 
post-actions  PASSIVE  RETR  and  VHRG  RFTR  from  the  level  of  the  verb  group  net  to  that 
of  the  sentence  net,  in  order  that  they  may  be  used  to  perform  tests  on  the  arcs  at 
state  S/VG.  The  value  of  PASSIVl  is  either  0 or  1 according  to  whether  the  sentence  is 
active  or  passive  (in  the  case  of  (1)  the  value  of  PASSIVF  is  0),  and  VHRG  contains  the 
verb  head. 

4.4.2. 2.4  State  S/I /G.  F rom  state  S/SUBJ  control  passes  to  state  S/VG  with  ‘OPL  RA- 
TIONS’ as  the  current  input  symbol.  Arc  1 at  S/VG  is  a push  to  the  agent  net,  with  the 
condition  that  the  contents  of  PASSIVF  be  1 and  that  the  current  input  symbol  be  ‘BY’. 
This  clearly  fails,  as  does  arc  2,  which  also  requires  that  the  contents  of  PASSIVE  be  1. 
Arc  3 is  a push  to  the  simple  noun  phrase  net  (state  SNP/),  with  the  condition  that  the 
contents  of  Passive  be  0 and  that  the  contents  of  VHRG  have  the  feature  TRANS  (tran- 
sitive) ‘CONDUCTING’  is  transitive,  so  control  transfers  to  state  SNP/  ‘OPERATIONS’  is 
identified  as  a simple  noun  phrase,  and  an  NP  node  is  built  and  returned  to  the  sentence 
net,  where  it  is  stored  in  the  register  OBJ.  Control  then  passes  to  state  S/OBJ  with 
'OVER'  as  the  current  input  symbol. 

4.4.2. 2. 5 Sfafe  S/OBJ.  The  arc  at  state  S/OBJ  is  a push  to  the  verb  modifier  net,  so 
control  passes  to  state  VM/.  The  pre-action  on  this  arc  sends  the  list  VMODS,  which 
already  contains  ‘AT  0200Z’  and  ‘21  FFBRUARY’,  down  to  the  level  of  the  verb  modifier 


net.  ‘OVER  THE  RED  SEA’  is  recognized  as  a verb  modifier  (more  specifically,  a preposi- 
tional phrase)  and  added  to  VMODS,  which  is  raised  to  the  level  of  the  sentence  net  by 
the  post-action  VMODS  RETL.  Control  then  passes  to  state  S/S. 

4. 4. 2.2.6  State  S/S.  The  pop  arc  at  S/S  builds  a five-branched  node  labeled  ‘S’.  The 
first  branch  points  to  the  contents  of  SUBJ,  the  second  to  the  contents  of  VGRG,  the 
third  to  the  contents  of  OBJ,  the  fourth  to  the  contents  of  COMPL,  and  the  fourth  to  the 
VMODS  list. 

4.4.2.3  The  Noun  Phrase.  The  noun  phrase  grammar  (see  Figure  4-5  and  Appendix  D) 
accepts  complex  noun  phrases  with  pre  and  post  head  modifiers,  including  adjectives, 
prepositional  phrases  and  relative  clauses  (both  full  relatives,  i.e.  those  that  contain 
relative  pronoun,  and  restricted  relatives.  It  returns  a four-branched  node  labeled  ‘NP’. 
The  first  branch  points  to  a determiner  phrase,  the  second  to  a list  of  pre-head  modif- 
iers, the  third  to  the  head  noun,  and  the  fourth  to  a list  of  post-head  modifiers.  Given 
(7),  for  example,  the  noun  phrase  net  produces  the  structure  given  as  (8). 

(7)  THE  FOUR  SR-71  RECONNAISSANCE  AIRCRAFT  FROM  REGIMENT 
XB412  WHICH  DEPARTED  HOMEBASE  AT  0200Z  WERE  ENROUTE... 

(8)  NP(DP(THE  FOUR), 

[SR-71,  RECONNAISSANCE], 

N(AIRCRAFT), 

[FROM  REGIMENT  XB412,  WHICH  DEPARTED  HOMEBASE  AT  0200Z]) 

(7)  is  parsed  by  the  noun  phrase  net  as  follows: 

4.4. 2.3. 7 State  NP/.  At  state  NP/  control  is  pushed  to  state  SNP/,  the  initial  state  of 
the  simple  noun  phrase  net.  In  our  terminology,  a simple  noun  phrase  is  one  which  has  no 
post-head  modifiers,  i.e.,  one  which  consists  of  at  most  a determiner  phrase,  a list  of 
pre-head  modifiers,  and  a head  noun.  ‘THE  FOUR’  is  recognized  by  the  simple  noun 
phrase  net  as  a determiner  phrase,  ‘SR-71’  and  ‘RECONNAISSANCE’  as  pre-head  modif- 
iers, and  ‘AIRCRAFT'  as  the  head  noun.  These  structures  are  stored  in  DPRG,  PREMODS, 
and  HNRG,  respectively,  which  are  raised  to  the  level  of  the  noun  phrase  net  by  the 
post-actions  on  the  push  arc.  Control  then  transfers  to  state  NP/SNP,  with  ‘FROM’  as 
the  current  input  symbol. 

4.4.2.3.2  State  NP/SNP.  The  arc  at  state  NP/SNP  is  a push  to  the  post-head  modifier 
net.  ‘FROM  REGIMENT  XB412’  and  ‘WHICH  DEPARTED  HOMEBASE  AT  0200Z’  are  recog- 
nized as  post-head  modifiers  and  added  to  the  list  POSTMODS,  which  is  raised  by  the 
post  action  ‘POSTMODS  RETL’  to  the  level  of  the  noun  phrase  net.  Control  then  passes 
to  state  NP/NP  with  ‘WERE’  as  the  current  input  symbol. 

4.4. 2.3. 3 State  NP/NP.  The  pop  arc  at  state  NP/NP  builds  a four-branched  node 
labeled  ‘NP’  The  first  branch  points  to  the  contents  of  DPRG,  the  second  to  the  list 
PREMODS,  the  third  to  the  contents  of  HNRG,  and  the  fourth  to  the  list  POSTMODS. 

4.4. 2.4  The  Verb  Group  Net.  The  verb  group  grammar  (see  Figure  4-6  and  Appendix  D) 
accepts  the  main  verb,  its  auxiliaries  and  any  associated  evaluative  adverbs.  It  returns 
a node  labeled  ’VG'  which  has  four  branches.  The  first  branch  points  to  a list  of  evalua- 
tive adverbs  (eg.  ‘POSSIBLY’,  or  ‘PROBABLY’),  the  second  to  the  verbal  auxiliary  (also  a 
list),  the  third  to  a copula,  and  the  fourth  to  the  verb  head.  Given  (9),  the  verb  group 
net  returns  the  structure  in  (10). 


1-49 


(9)  ...HAVE  POSSIBLY  BEEN  CONDUCTING  FLIGHTS  OVER  THl  RED  SI  A. 


(10)  VG([ 'POSSIBLY']. 

['HAVE’, 'BEEN'], 

0. 

‘CONDUCTING’) 

(9)  is  parsed  by  the  verb  group  net  as  follows: 

4.4. 2. 4.1  State  l /G/.  The  arc  at  state  VG/  is  a push  to  the  auxiliary  net.  ‘HAVE’  and 
‘BEEN’  are  recognized  as  auxiliary  elements  and  placed  in  the  list  AUX,  and  the  evalua- 
tive adverb  ‘POSSIBIY’  is  placed  in  the  list  ADVBLST.  AUX  and  ADVBLST  are  raised  to  the 
level  of  the  verb  group  net  by  the  post-actions  AUX  RETL  and  ADVBLST  RETL,  and  control 
passes  to  state  VG/AUX  with  ‘CONDUCT  ING'  as  the  current  input  symbol. 

4.4. 2.4. 2 State  1/G//U/X.  Arcs  1 and  2 test  for  the  features  COPULA  and  BE,  respec- 
tively, and  both  fail,  since  'CONDUCTING'  has  neither  of  these.  Arc  3 succeeds,  and 
‘CONDUCTING’  is  stored  in  the  register  VHRG.  Controi  then  passes  to  state  VG/VH. 

4.4. 2.4. 3 State  VG/VH.  The  pop  arc  at  VG/VH  builds  a four-fcranched  node  labeled  ‘VG’. 
The  first  branch  points  to  the  list  ADVBLST,  the  second  to  AUX,  ihe  third  to  the  contents 
of  CPRG  (which  in  this  case  is  empty),  and  the  fourth  to  the  contents  of  VHRG. 

For  (11),  the  verb  group  net  returns  the  structure  given  in  (12),  and  the  parsing 
proceeds  as  follows. 

(11)  ...HAVE  BEEN  ACTIVE  OVER  THL  RED  SLA 

(12)  VG([], [‘HAVE’], ‘BEEN’,  ACTIVE’) 

4.4.2. 4.4  State  VG/.  This  time  the  push  to  the  auxiliary  net  returns  an  AUX  list  with 
’HAVE’  as  its  only  member.  'BEEN'  is  determined  not  to  be  an  auxiliary  element,  since  it  is 
not  followed  by  a progressive  verb  form.  Control  passes  to  state  VG/AUX  with  BEEN'  as 
the  current  input  symbol. 

4. 4. 2. 4. 5 State  VG/AUX.  Arc  1 at  state  VG/AUX  tests  for  the  feature  COPUI  A.  'BEEN’ 
has  this  feature,  so  the  transition  is  made  to  state  VG/COP  and  ‘BEEN’  is  placed  in  the 
register  CPRG.  The  current  input  symbol  is  now  ‘ACTIVE’. 

4. 4. 2. 4. 6 State  VG/C.OP.  Arcs  1 and  2 at  VG/COP  test  for  adverbs,  so  both  of  these 
fail.  Arc  3 succeeds,  so  ‘ACTIVE’  is  placed  in  the  register  VHRG  and  control  passes  to 
state  VG/VH. 

4.4. 2. 4. 7 State  VG/VH.  The  pop  arc  at  state  VG/VH  builds  the  structure  given  in  (12). 

As  a final  example,  consider  the  verb  group  in  (13). 

(13)  FLIGHTS  HAVE  BEEN  CONDUCTED  BY  AIRCRAFT  FROM  RGT  XR412. 

4. 4. 2. 4.8  State  VG/.  The  push  to  the  auxiliary  net  retuns  an  AUX  list  containing  ‘HAVE’. 
Control  passes  to  state  VG/AUX  with  'BEEN'  as  the  current  input  symbol. 

4. 4. 2. 4.9  State  VG/AUX.  Since  Bt  I N‘  has  the  feature  COPULA  (although  in  (13)  it  is  not 
used  as  such),  arc  1 succeeds  and  'BEEN’  is  stored  in  CPRG.  Control  passes  to  state 
VG/COP  with  ‘CONDUCTED’  as  the  current  input  symbol. 
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4.4.2.4.10  State  I /G/COP.  Arcs  1,  2 and  3 at  state  VG/COP  each  fail,  since  ‘CON- 
DUCTED’ is  neither  an  adverb  nor  an  adjective.  The  parser  backs  up  to  state  VG/AUX, 
undoes  the  action  on  arc  1,  and  attempts  arc  2 with  ‘BEEN’  as  the  current  input  symbol 
Arc  2 succeeds,  so  the  transition  is  made  to  state  VG/BE  with  ‘CONDUCTED’  as  the 
current  input  symbol. 

4.4.2.4.11  State  VG/BE.  Arcs  1 and  2 at  VG/BE  both  fail.  Arc  3,  which  tests  for  the 
feature  PASTP  (past  participle),  succeeds,  so  ‘CONDUCTED’  is  stored  in  VHRG  and  PAS- 
SIVE is  given  the  value  1.  Control  passes  to  state  VG/VH  with  ‘BY’  as  the  current  input 
symbol. 

4.4. 2.4.1 2 State  VG/VH.  The  pop  arc  at  state  VG/VH  builds  the  structure  given  in  (14). 
In  addition,  the  contents  of  PASSIVE  will  be  used  at  the  level  of  the  sentence  net  to 
determine  that  (13)  is  a passive,  and  the  sentence  net  will  thus  return  the  structure 
given  in  ( 1 5). 

(14)  VG([],[ ‘HAVE ’],0, ‘CONDUCTED’) 

(15)  S(NP(AIRCRAFT  FROM  RGT  XB412), 

VG(HAVE  CONDUCTED), 

NP(FLIGHTS), 

0, 


Mgurp  4-7.  The  Verb  Modifier  Net 


4.5  Template  Descriptor  Selection:  Methodological  Issues 

This  section  provides  a general  discussion  of  some  fundamental  Issues  pertaining  to  the 
selection  of  descriptors  for  templates  relating  to  any  subject  domain  in  general,  and 
lists  the  descriptor  system  developed  so  far  for  the  domain  of  aircraft  activities  in  par- 
ticular. 

4.5. 1 User-Related  Considerations 

The  set  of  properties  used  for  the  description  of  events  relating  to  a particular  subject 
domain  must  answer  the  what,  who,  where,  when,  and  why  information  questions 
relevant  to  the  analyst  s task.  The  definition  of  the  descriptors  and  their  organisation, 
therefore,  must  be  consonant  with  the  analyst’s  view  of  the  world. 

In  general,  any  number  of  properties  may  be  specified  for  any  given  class  of  entities. 
However,  not  all  properties  have  the  same  degree  of  usefulness  in  a given  context.  The 
properties  selected  tor  inclusion  in  a template  must,  therefore,  be  sensitive  to  the  task 
the  template  Is  designed  to  support.  Accordingly,  the  first  criterion  for  selection  is  that 
of  relevance,  templates  must  include  only  that  information  which  is  particularly  relevant 
and  useful  to  the  task  at  hand,  and  not  the  full  range  of  facts  one  might  find  in  an  ency- 
clopedia. 

4.5.2  Linguistic  Considerations. 

In  this  subsection  the  discussion  will  evolve  around  the  linguistic  criteria  tor  descriptor 
selection. 

Broadly  speaking,  descriptors  fall  into  two  major  categories  those  that  involve  "deep 
case"  relations,  and  those  that  involve  inferences  of  a special  kind.  "Deep  cases"  are 
binary  relations  which  specify  an  event  regardless  of  the  surface  realization  of  that 
event  description  as  a sentence  or  a noun  phrase.  The  descriptors  involving  inferences 
are  restricted  to  those  which  have  to  do  with  the  relations  of  entailment  and  presupposi- 
tion. 

Descriptors  selected  for  Inclusion  in  templates  within  a particular  subject  domain  are 
pragmatically  determined  from  a linguistic  and  logical  analysis  of  a representative  sample 
of  Intelligence  messages.  The  criterion  used  for  selection  of  "deep  case"  relations  is 
the  following: 

A deep  case  is  a relation  whose  value  is  usually 
specified  for  a given  event  type. 

Thus,  flight  reports  include  a description  of  the  object(s)  which  is  (are)  doing  the  flying 
and  frequen  ly  mention  other  relations  such  as  the  source  of  the  flight,  its  direction,  the 
area  overflown,  the  destination,  and  the  mission.  These  properties  are  assigned  the 
status  of  "deep  cases"  in  the  sense  specified  above. 

Pilots,  however,  or  navigators,  are  very  seldom  mentioned  in  flight  reports.  They  will  be 
treated  differently,  namely,  they  will  be  regarded  as  presupposition  of  the  flight  event. 
The  notions  of  entailment  and  presupposition  are  explicated  in  a later  subsection  The 
next  section  discusses  the  notion  of  "deep  cases",  which  is  the  basis  for  defining  intra- 
template relations. 

4.5.2. 1 The  'Deep  Case'  System. 

A "deep  case"  is  a binary  relation  which  holds  between  a predicate  (usually,  but  not 
necessarily,  realized  as  a verb)  and  one  of  its  arguments.  Deep  cases  are  used  both  in 


accounting  for  the  relative  acceptability  of  natural  language  sentences  and  in  t xplaining 
how  an  Intelligent  system  might  understand  language.  This  Is  done  In  terms  of  a "case 
structure"  and  "selectional  restrictions".  The  case  structure  for  any  predicate  is  the 
set  of  cases  allowed  in  a description  of  that  predicate.  Selectional  restrictions  then 
place  semantic  constraints  on  the  objects  which  fill  the  case  slots. 

Each  predicate  has  a number  of  cases.  These  may  include  adverbial  modifiers,  temporal 
Indicators,  and  other  propositions  as  well  as  the  usual  nominal  cases.  For  example,  the 
case  structure  for  the  predicate  "be  enroute"  might  be  (Object,  Destination),  where 
each  case  may  appear  at  most  once.  Object  represents  the  notion  "The  thing  which  is 
enroute".  The  meaning  of  Destination  is  clear.  Roth  the  Object  and  the  Destination  must 
be  present  in  the  message  text;  l.e.,  they  are  obligatory  cases  which  are  required  for 
the  event  description  to  make  sense. 

Other  predicates  may  have  allowable  cases  which  need  not  necessarily  be  realised  in 
the  text.  Such  a predicate  is  "fly",  for  which  only  the  "thing  which  is  doing  the  flying"  is 
obligatory.  The  other  allowed  deep  cases,  such  as  Source,  Destination,  fcxtent,  Direc- 
tion, Area,  Mission,  etc.,  are  optional,  i.e.,  they  may  or  may  not  appear  in  the  actual  text. 
Any  of  the  following  sentences  satisfies  the  descriptor  structure  for  the  fly  template. 

The  aircraft  flew  south. 

The  aircraft  flew  to  Mombasa. 

The  aircraft  flew  from  London  to  Cairo. 

The  aircraft  flew  as  far  south  as  Cairo. 

The  aircraft  flew  a reconnaissance  mission  over  Uganda  between 
0012  and  0036  on  26  Feb  1976. 

However,  if  the  first  and  last  sentences  refer  to  a single  aircraft,  based  on  one  message 
or  more  than  one,  the  additional  information  provides  material  to  complete  the  empty 
descriptor  slots  in  the  ’flight’  template  representing  that  event.  Selectional  restrictions 
vary  from  global  constraints  on  the  use  of  a case  (e.g.,  "every  agent  must  be  animate") 
to  local  constraints  on  the  use  of  a case  with  a particular  predicate  (e  g.,  "the  destina- 
tion of  a flight  must  be  a geographic  location  such  as  a country,  a city,  or  an  airport"). 

The  degree  to  which  a case-based  theory  can  account  for  the  correct  interpretation  of 
text  depends  upon  the  way  the  cases  mediate  between  surface  forms  and  conceptual 
structures.  The  transformation  of  surface  forms  into  meaning  representations  is  the 
function  of  the  procedural  component  of  templates,  which  was  described  in  So.  inn  3. 

4.S.2.2  Presupposition  and  Entailment. 

Presupposition  and  entailment  are  a subclass  of  inferences  which  appear  to  be  closely 
connected  with  the  structure  of  language.  Ihey  arise  from  two  main  structural  sources: 
one,  the  semantics  of  particular  words,  and  two, from  the  syntactic  (or  relational)  struc- 
ture of  sentences. 

4.6 .2.2.1  Entailment.  A proposition  P entails  a proposition  P’  If  and  only  if  in  every  con- 
text in  which  P is  true,  P’  is  also  true.  For  example,  a plane  cannot  fly  unless  it  has 
taken  off,  cannot  land  unless  it  has  been  flying,  must  be  in  flight  if  it  has  taken  off  and 
has  not  landed  or  been  destroyed  Thus  a take-off  event  entails  a subsequent  flight, 
while  a flying  event  entails  a preceding  take-off.  A landing  event  entails  a precede -j 
flight,  while  a flying  event  entails  a subsequent  landing. 

The  above  entailment  relations  are  obligatory  and  specific  to  the  respective  event 
predicate,  i.e.,  a flight  entails  a previous  take-off  because  of  the  meaning  of  "fly",  while 


a landing  entails  a previous  flight  because  of  the  meaning  of  "land". 

Such  entailments  predict  the  normal,  expected,  ordering  of  events  in  the  air  activities 
world.  Any  violation  of  these  expectations  can  serve  as  a warning  to  the  analyst  that 
some  external  force  has  altered  the  predicted  course  of  events. 

For  example,  If  a plane  which  is  reported  In  flight  does  not  land  within  expected  limits  of 
time,  it  may  have  altered  course,  may  nave  made  a force-landing,  or  may  have  been  des- 
troyed. It  Is  Important  that  the  analyst  be  alerted  to  any  deviation  from  the  expected. 

4.5. 2.2.2  Presupposition.  A second,  related  concept  is  the  notion  of  presupposition.  A 
proposition  P (logically)  presupposes  a proposition  P’  if  and  only  if  P entails  a P’  and  ~P 
entails  P\  Therefore,  whether  P is  true  or  false,  P'  must  be  true  If  P is  to  make  any 
sense  at  all.  It  is  clear  from  the  above  definition  that  all  logical  presuppositions  P’  are 
also  entailments  of  P.  Presuppositions  play  an  important  part  in  the  meaning  of  many 
words. 

For  example,  in  the  air  activities  domain,  a flying  event  presupposes  that  the  thing  which 
does  the  flying  is  an  aircraft.  The  presupposition  is  related  to  selectional  restrictions 
and  Is  incorporated  In  the  specification  of  what  may  fill  the  Object  slot  of  the  FLY  event. 

Certain  aspectuals  (e  g , begin,  continue,  end)  are  also  associated  with  presuppositions. 
For  example,  both  the  sentence  "the  plane  continued  flying"  and  its  negation"the  plane 
did  not  continue  flying  presuppose  that  at  some  point  the  plane  was  flying. 

The  predicate  "return"  presupposes  that  the  object  which  is  reported  to  have  returned 
has  been  at  that  location  before. 

One  of  the  important  aspects  of  presupposition  in  language  is  that  it  informs  the  reader 
that  the  presupposition  must  be  considered  true.  Thus,  if  some  aircraft  is  reported  to 
have  returned  to  its  normal  operating  area,  it  must  be  considered  true  that  some  time 
before  its  return  it  took  off  from  that  particular  area.  Even  if  the  report  were  negative, 
i.e.,  stating  that  the  aircraft  in  question  had  not  returned  to  its  normal  operating  area, 
the  presupposition  that  it  had  previously  taken  off  from  that  area  remains  true. 

Thus,  presuppositions  and  entailments  add  Information  which  is  conceptually  associated 
with  some  entity,  but  Is  very  seldom  mentioned  explicitly. 

This  fact  can  be  of  assistance  to  the  analyst  in  establishing  the  identity  of  objects 
involved  in  events  imported  by  different  sources  in  different  ways,  or  perhaps  in  seeking 
to  establish  links  between  events  which  otherwise  might  appear  unconnected. 

The  descriptor  system  for  the  air  activities  sublanguage  then,  includes,  in  addition  to 
ttiose  discussed  previously,  the  two  descriptors  related  to  inferences,  namely,  entail- 
ments and  presuppositions. 

4.5.3  The  Descriptor  System  for  the  Aircraft  Domain  Table  4-24  shows  the  descriptor 
system  so  far  developed  for  the  air  activities  sublanguage. 
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Table  4-24.  Air  Activities  Descriptor  System 
+ . 


A.  Motion  related  descriptors 
Agent 
Object 


Source 

Destination 


Direction 

Path 
Extent 
Limit 
Altitude 

Region 
Status 

Time  specification 

B.  Event  related  descriptors 
Mission 

C.  Aircraft  related  descriptors: 

Equipment 
Class 

NATO  designation 
National i ty 
Subordination 
Homebase 
Staging  base 
Set  specification 
Configuration 

D.  Inferences 

Entailments 
Presupposition 
The  latter  include  objects  normally 
concepts  but  very  seldom  mentioned, 


Animate  instigator  of  the  action.  I 
The  entity  that  moves  or  changes  or  I 
whose  position  or  existence  is  being  ! 
described.  I 
The  location  of  the  object  at  the  | 
beginning  of  a motion.  I 
Projected  or  actual  destination  I 
of  the  object  at  the  end  of  the  I 
motion.  I 
Direction  of  motion  of  object  at  timel 
of  observation.  I 
Path  or  area  traversed  during  motion. I 
Extent  of  motion.  I 
Limit  of  motion.  I 
Altitude  of  object  at  time  of  I 
observation.  I 
General  location  of  the  action.  I 
Begin,  continue,  end.  I 
Time  of  observation  or  duration  of  | 
the  event.  I 

Purpose  of  flight.  I 


th  some 
fuselage) . 


associated  wi 
(e.g.,  pilot, 
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1.0  Introduction 


This  section  describes  the  implementation  of  the  concepts  of  the  first  section,  in  the 
form  of  the  MAI  RES  II  system.  The  following  subsections  describe  the  various  com- 
ponents of  the  system.  In  some  places,  references  are  made  to  MATRFS  I,  the  product 
of  the  contract  directly  preceding  the  current  one.  The  reader  is  referred  to  the  final 
report  of  that  contract  for  details. 

Subsection  2 presents  the  data  structures  and  algorithms  for  the  sentence  input  and 
grammar  processing  vocabulary;  this  vocabulary  is  essentially  an  extensive  modification 
of  the  MAI  RES  I system.  Subsection  3 describes  the  capabilities  added  in  the  area  of 
morphology.  The  implementation  of  the  ERL  evaluation  process,  including  the  abstract 
machine  which  is  the  target  language  of  ERL,  is  described  in  Subsection  4.  The  ERL 
compiler,  which  is  the  only  non-Forth  module,  is  discussed  in  Subsection  5.  The  last 
three  subsections  are  intended  as  a guide  to  the  Forth  program  files  listed  in  Appendix 
A,  and  provide  glossaries  of  the  Words  in  those  files. 


2.0  Design  of  Lexical  and  ATN  Processors 

2.1  General  Principles 

All  operations  involving  addresses  use  a set  of  Words  which  expect  addresses,  even  if 
the  operations  are  simple;  e.g.  to  increment  an  address  "p"  by  "n"  words  (bytes),  use  "p 
n a+"  ("p  n \a+"),  where  "a+"  and  "\a+“  are  defined  as: 

: a+  2*  + ; : \a+  + ; 

Note  that  these  words  are  not  commutative,  and  expect  the  address  on  20S. 

Of  course,  any  FORTH  Word  may  be  used  as  an  action,  but  it  should  be  remembered  that 
actions  may  have  to  be  undone;  therefore,  action  Words  should  not  modify  storage  out- 
side of  the  context  blocks. 

For  the  purposes  of  defining  structure,  we  assume  that  structures  will  only  be  built  and 
examined,  not  modified  or  deleted;  all  dynamic  storage  will  be  released  when  a sentence 
has  been  completely  processed.  Later  enhancements  may  require  a dynamic  space  rec- 
lamation mechanism,  but  we  don’t  make  any  provision  for  that  now. 

2.2  Data  Structures 

All  the  following  structures  reside  in  block  storage  to  provide  for  uniformity  of  address- 
ing, since  we  use  a 16-bit  address  for  block  storage  similar  to  the  one  used  in  IS.W  II  for 
data  base  pointers;  these  pointers  cannot  be  distinguished  from  core  addresses  by  their 
content  alone. 

The  lexical  unit,  as  defined  below,  is  different  from  that  of  l&W  II;  here  we  treat  dif- 
ferent senses  of  words  having  multiple  senses  as  distinct  lexical  units,  and  use  forward, 
backward  and  alternate  pointers  to  link  units  within  the  sentence,  tnus  creating  a "two- 
dimensional"  list  of  lexical  units  for  the  sentence. 

A lexical  unit  has  a string  pointer,  a string  length,  a forward  pointer  (to  the  next  unit  in 
the  sentence),  a backward  pointer  (to  the  previous  unit),  an  alternate  pointer  (to 
the  next  sense  unit  for  the  current  word  or  phrase),  and  a sense. 

A register  is  empty  or  contains  a pointer  to  a lexical  unit  or  a list  or  a node. 

A node  has  a label  and  one  or  more  branches;  a branch  is  empty  or  points  to  a lexical 

unit  or  a list  or  a node;  a label  is  the  name  of  a Word  which  contains  a branch 
count  and  the  label  name  (in  the  format  of  an  ERL  functor  literal;  see  the  section 
on  ERL). 

A list  has  a zero  branch  count  and  a link  to  the  first  listel;  a listel  has  a pointer  to  a lex- 
ical unit  or  a list  or  a node,  and  a link;  a link  points  to  a listel  or  is  zero. 

2.3  Action  Definitions 

The  actions  for  IftW  III  are  totally  different  from  the  previous  ones;  for  convenience,  we 
will  repeat  the  syntax  definitions  from  MATRES  here,  with  new  rules  for  declarations  and 
actions  (note  that  "b"  represents  a blank  that  must  be  present). 

grammar  ;;=  'GRAMMARS  start-state-name  declaration*  state*  'bENDGRAMMAR' 

start-state-name  ::=  state-name 

declaration  ::=  ’bREGISTF.Rb’  register-name  | ’bUSTb’  list-name  | number  ’blABELb’ 
label-name 
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register-name,  list-name,  label-name  ::=  Word 
state  : * : Si6’  state-name  arc+  'b;;' 
state-name  ::=  Word 
arc  ::=  ':WRDb'  ’"b’  string  tail  | 

’:MEMb'  ’(»’  ( ’"|6’  string  )+  ’16V  tail  j 
’ :CA T 16’  [ ] '[16’  feature*  '16}'  tail  | 

’:TSfb’  condition  '161*16'  action*  ’b=>b’  state-name  'b,,b'  | 

’:PSH|6’  [ condition  'bl'b'  ] action*  '(6TOI6’  state-name  action*  ’16=>  16*  state-name 
'b„b'  | 

’:POPb'  [ condition  '16* ' 16’  ] action*  ptr  '16, .16'  ) 

JUMPb'  state-name  [ condition  ’)61 116'  ] action*  [ 'bADVb'  | ’bRETb’  J 'b,,b’ 
tail  [ condition  ] '16! ( 16'  action*  'b=>b'  state-name  ’!6..t6* 
condition  ::=  condition  condition  ( 'bANDb  ) 'bORb'  ) ) condition  'bNOTb'  | cond 
cond  ::=  pos  test  | Word 

test  ::=  [ J ‘"b’  string  | [ ] '[b’  feature*  'bj'  | 'b[EOS]b' 

action  Word  ) ptr  register-name  'bSETRb'  | register-name  'bGETRb'  | ptr  list-name 
'bADDLISTb'  j ptr  register-name  'bSENDRb'  | register-name  'bRElRb'  | list-name  ( 
’bSENOLb’  | ’bRETLb'  ) 

ptr  ::=  pos  | register-name  'bGETRb'  | list-name  | ptr*  label-name  'bNODEb' 

pos  ’b*b’  1 ’b*+1b’  ! ’b*-1b'  | register-name  'bGETRb' 

A "ptr"  construction  returns  to  the  stack  a pointer  to  a lexical  unit,  a list,  or  a node;  in 
the  latter  case,  the  node  is  actually  created  by  the  Word  NODE  from  the  label  and  "ptr"s 
ori  the  stack.  The  label  preceding  NODE  must  have  been  declared  by  a LABEL  declara- 
tion which  gives  the  number  of  pointers  to  take  from  the  stack;  for  example,  the 
declaration  "4  1ABFI  THING",  together  with  the  action  "REG  @ *+1  *-1  LIST  THING  NODE" 
creates  a node  labelled  THING  with  four  branches,  the  first  pointing  to  the  list  LIST,  the 
second  to  the  previous  lexical  unit,  the  third  to  the  next  lexical  unit,  and  the  fourth  to 
what  REG  points  to.  A pointer  to  the  list  is  returned  to  the  stack.  Note  that  the  order  of 
pointers  in  the  node  is  the  reverse  of  the  order  in  which  they  appear  in  the  text. 

ADDLIST  adds  a ptr  to  the  front  of  the  specified  list;  thus,  as  with  nodes,  the  elements 
of  the  list  will  be  in  reverse  order  from  that  which  they  were  added. 

SETR  is  used  to  set  a register  to  a value,  and  GETR  is  used  to  retrieve  the  value  of  a 
register.  GETR  may  be  used  in  tests,  with  registers  which  point  to  lexical  units 

SENOR  and  SENDl  are  used  only  in  the  preactions  of  a PUSH  node.  SENDR  sends  a value 
to  a register  at  the  level  of  the  subnet  (registers  and  lists  are  normally  empty  on  entry 
to  a subnet).  Similarly,  SENDL  sends  the  current  value  of  a list  to  the  subnet  level. 

RETR  and  RE1L  are  used  only  in  the  postactions  of  a PUSH  node,  and  are  complementary 
to  SENDR  and  SENDL,  in  that  they  retrieve  register  and  list  values,  respectively,  from  the 
subnet  values  at  the  time  of  the  POP. 
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A POP  arc  must  have  a "ptr"  as  its  last  (or  only)  action,  which  will  cause  the  "ptr"  to  be 
assigned  to  * at  the  next  level  up. 

2.4  Internal  Structure  and  Algorithm  Specifications 

2.4. 7 Layout  of  Block  Storage  All  the  system  structures  except  the  compiled  ATN  reside 
In  block  storage  to  provide  for  uniformity  of  addressing,  since  we  use  a 16-bit  address 
for  block  storage  similar  to  the  one  used  in  l&W  II  for  data  base  pointers;  these  pointers 
cannot  be  distinguished  from  core  addresses  by  their  content  alone. 

The  first  structure  in  block  storage  is  the  lexicon,  starting  at  the  block  specified  by  the 
constant  SLEX.  The  variable  ELEX  holds  a pointer  to  the  last  byte  of  the  lexicon.  Next, 
starting  on  the  next  block  boundary,  will  be  the  text  of  each  input  sentence,  followed  by 
the  chart  for  that  sentence,  and  then  the  stack  of  state  frames.  The  base  block  number 
for  all  pointers  except  within  the  lexicon  will  be  contained  in  the  constant  SBASE. 

2.4.2  Structure  of  the  Input  Sentence  As  described  below,  each  input  sentence  will  be 
read  and  stored  in  FORTH  block  storage  in  two  parts:  the  actual  character  string 
comprising  the  sentence,  and  a structure  of  entries  corresponding  to  the  lexical  units 
(words  or  phrases)  found  in  the  sentence.  Each  such  entry  has  the  following  structure: 

Item  Length 

Address  of  chai_cter  string  for  unit  1 word 
Length  of  character  string  (in  bytes)  1 word 
Pointer  to  next  unit  1 word 

Pointer  to  previous  unit  1 word 

Pointer  to  alternate  unit  1 word 

Feature  vector  NWRD  words 

At  the  end  of  the  list  of  entries  Is  a "pseudo-entry"  consisting  of  all  zero  entries  except 
for  the  previous  unit  pointer,  to  mark  the  end  of  the  sentence. 

This  structure  allows  for  a list  of  alternate  senses  for  a given  word  in  the  sentence,  and 
also  for  handling  phrases.  For  example,  it  may  or  may  not  be  appropriate  to  treat  a given 
sequence  of  words  as  a single  lexical  unit  at  a particular  place  in  a sentence;  with  this 
structure,  we  could  build,  as  alternates,  both  the  lexical  unit  corresponding  to  the 
phrase  interpretation  and  the  list  of  units  corresponding  to  the  string  of  words  (although 
we  don't  do  that  in  this  system).  We  will  call  the  structure  built  for  a sentence  the  chart 
of  the  sentence. 

The  following  variables  are  set  to  provide  access  to  these  structures: 

TXTP  points  to  the  first  character  of  the  sentence  text. 

SENTP  points  to  the  first  lexical  unit  of  the  sentence  chart,  and  also  marks  the  end  of 
the  sentence  text. 

FRAMSTRT  points  to  the  base  of  the  first  state  frame  for  the  sentence,  and  also  marks 
the  end  of  the  chart  for  the  sentence. 

2.4.3  Text  Input  and  Sentence  Construction  Text  input  is  performed  by  the  Word 
GETTXT  and  its  auxiliary  Words.  The  FORTH  Word  WORD  is  used  to  get  the  next  string 
of  nonblank  characters,  and  CHKWRD  strips  off  trailing  commas  and  periods,  and  returns 
an  Indication  if  the  punctuation  was  a period;  this  is  used  to  terminate  the  sentence 
text.  Words  will  be  separated  by  one  blank,  and  a period  set  off  by  blanks  will  be 


appended  to  the  text  (by  TEXFIN). 

MAKESENT  makes  the  chart  of  the  sentence,  creating  a lexical  unit  for  each  sense  of 
each  word  or  phrase  found  in  the  lexicon,  and  linking  them  as  appropriate.  Its  operation 
is  discussed  in  more  detail  in  the  next  section. 

2.4.4  ATN  Processor  - Data  and  Program  Structures  The  ATN  compiler  produces  a Word 
In  the  dictionary  for  each  state,  having  code  structures  for  each  arc;  these  are 
described  below.  By  "code"  is  meant  a COLON-style  sequence  of  Words  implementing  a 
particular  operation.  Optional  elements  of  a structure  are  delimited  by  square  brackets  - 
All  states  are  encompassed  in  a scope  block  named  "GRMDF". 

2. 4.4.1  State  Structure 

State  entry  code 

Arc  structures  for  arcs  of  state 

End-of-state  code 

2. 4.4.2  Arc  Structures  ( by  arc  type) 

WRD,  MEM,  Arc  entry  code 

CAT,  TST  Code  for  tests  - leaves  1 or  2 truth  values  on  stack 
Code  for  !! 

[Code  for  actions] 

Code  for  =>  and  state  name 

Arc  entry  code 
[Code  for  tests 
Code  for  !!] 

[Code  for  preactions] 

Code  for  TO  and  state  name 
[Code  for  postactions] 

Code  for  =>  and  state  name 

Arc  entry  code 
[Code  for  tests 
Code  for  !!] 

[Code  for  actions] 

Code  for  returning  to  calling  arc 

Arc  entry  code  - 3rd  and  4th  words  are  skip  around  state 
name 

[Code  for  tests 
Code  for  !!] 

[Code  for  actions] 

[Code  for  ADV  or  RET] 

Code  for  jumping  to  state 

In  all  arc  types,  the  first  two  words  of  the"arc  entry  code"  comprise  a word  pointing  to 
the  next  arc  (or  to  the  end-of-state  code),  then  the  FORTH-style  code  word  (a  pointer 
to  COLON). 


PUSH 


POP 


JUMP 


2.4. 5 Operation  of  the  ATN  Processor  The  operation  of  the  ATN  executive  processor  for 
state-to-state  transitions  would  be  almost  trivial  were  it  not  for  the  fact  that,  for  natural 
language  processing,  the  ATN  must  be  considered  non-deterministic.  For  example,  it  is 
possible  to  have  two  arcs  leaving  a given  state  with  the  same  tests  but  different  desti- 
nation states.  As  a result,  it  must  be  possible  to  backtrack  along  a path  to  a previous 
state,  undoing  any  actions  along  the  way. 

In  MATRES,  this  is  implemented  as  follows:  when  an  arc  is  successfully  traversed,  the 
current  computation  context  is  pushed  onto  the  dictionary,  and  a new  context  esta- 
blished. Thus  the  stack  of  contexts  describes  the  currently  active  path  through  the 
ATN.  When  the  last  arc  in  a state  is  tried  unsuccessfully,  backtracking  is  done  by  simply 
popping  the  stack  and  restoring  the  previous  context,  which  includes  a specification  of 
the  next  arc  to  try  in  the  (once  again)  current  state. 

The  context  referred  to  above,  which  will  subsequently  be  referred  to  as  a state  frame 
to  avoid  confusion  with  the  linguistic  sense  of  "context",  comprises  a base  pointer 
(FRAMBASE)  and  a set  of  value  cells  associated  with  various  item  names.  Each  name  is 
defined  as  an  offset  from  the  base  pointer  by  the  ITEM  defining  Word.  The  dictionary 
pointer  is  kept  pointing  just  past  the  current  frame,  and  the  base  pointer  is  pointing  to  a 
"hidden"  cell  containing  the  previous  base  pointer;  thus  a new  state  frame  may  be 
defined  by  simply  moving  the  base  pointer  to  agree  with  the  dictionary  pointer  and  set- 
ting the  dictionary  pointer  above  the  item  with  the  highest  offset,  and  an  old  frame 
restored  by  setting  the  dictionary  pointer  to  the  base  pointer  and  restoring  the  base 
pointer  from  the  cell  it  points  to.  This  scheme  allows  the  dynamic  addition  of  data  to  the 
current  frame  by  simply  advancing  the  dictionary  pointer. 

The  following  data  items  are  present  in  each  stack  frame: 

STAR:  special  register,  kept  ident'cal  to  LEX  except  on  return  from  a PUSH 

LEX:  pointer  to  current  lexical  unit 

STAAT:  pointer  to  current  state  structure 

ARC:  pointer  to  current  arc  structure 

ARCNO:  current  arc  number  within  state;  used  for  trace  printing 

RETRN:  contains  the  1C  to  return  to  on  POP,  and  the  base  pointer  associated  with  the 
state  from  which  the  last  PUSH  was  done 

Register  values  and  list  heads  are  allocated  above  these  items,  followed  by  dynamic 
allocations  of  nodes  and  list  elements. 

The  Word  NEWFRAME  is  used  to  establish  a new  frame.  It  sets  up  a new  state  frame  as 
described  above  and  copies  all  the  previous  item  data  into  it.  The  complementary  word, 
OLDFRAME,  restores  the  previous  frame  as  described  above. 

The  actual  transition  to  a new  state  is  done  in  two  steps.  First,  the  code  doing  the  tran- 
sition, which  has  the  name  of  the  new  state  stored  within  it,  calls  FNDSIATE,  which  finds 
that  name  in  the  dictionary  and  returns  its  code  word  on  the  stack  and  in  STAAT.  Next, 
a SKPTO  is  called,  and  it  transfers  control  to  the  address  on  the  top  of  tne  stack.  Note 


that  this  is  done  at  the  same  level  of  the  return  stack. 
2.4.5. 1 Algorithms  for  ATN  Processor  Elements 


Element 

State  Entry 
Arc  Entry 


POP  Return 


End  of  State 
ATN  Start 


ATN  Finish  Print  structure  in  STAR  if  tracing;  return  to  caller  of  PARSE 

2. 4.5. 2 Code  Structures  for  Tests  Here  we  show  the  structures  compiled  for  each  type 
of  test  in  the  arc  condition  section.  In  the  case  of  multiple  tests,  two  consecutive  tests 
will  be  followed  by  a reference  to  AND  or  OR.  A capitalized  word  shown  here  means  a 
reference  to  the  appropriate  Word. 

The  Word  SKIP  causes  the  1C  to  be  set  to  the  contents  of  the  following  word,  thus  skip- 
ping intermediate  words.  CMPWRD  and  NEGWRD  compare  the  literal  string  pointed  to  by 
TOS  with  the  string  from  the  lexical  unit  pointed  to  by  20S,  and  return  true  or  false, 
respectively.  TSTCAT  and  NEGCAT  cneck  that  the  feature  vector  pointed  to  by  TOS  is  a 
subset  of  the  feature  vector  in  the  'xical  entry  pointed  to  by  20S  (i.e.  that  the  logical 
AND  of  the  vectors  is  equal  to  the  vector  pointed  to  by  TOS).  [EOS]  checks  that  TOS 
points  to  the  end-of-sentence  lexical  unit.  LIT  puts  the  following  word  on  TOS. 


Algorithm 

Set  ARC  to  first  arc  in  state,  go  through  ARC 
NEWFRAME 

If  two  conditions  present,  AND  them; 

If  top  of  stack  true,  put  pointer  to  next  lexical  unit  on  stack 
(current  unit  if  JUMP  arc);  if  PUSH  arc,  set  SNDP  to  top-of- 
dictionary  in  case  a SENDR  is  done; 

If  false,  OLDFRAME,  set  LEX  to  next  alternate  lexical  unit  (if  no 
next  alternate,  reset  to  first  alternate,  update  ARC),  go  through 
ARC 

Top  of  stack->LEX,  get  called  state,  go  to  it 

Assign  "IC  + 1"  and  previous  base  pointer  to  RETRN,  clear  registers 
and  lists,  move  in  any  SENDRs  from  top  of  dictionary,  get  called 
state,  go  to  it 

Get  1C  and  base  pointer  from  RETRN,  copy  base  pointer’s  registers 
and  lists,  arc,  state,  and  return  data  into  current  frame,  TOS  into 
STAR,  go  to  postactions  through  1C 

Treat  like  false  branch  of  !! 

Set:  LEX  to  first  lexical  unit,  STAAT  to  ATN  start  state,  RETRN  to 
ATN  finish  code;  go  through  STAAT 


WRD  ( " string"  and  string")- 
SKIP 

pointer  to  LIT  word 
number  of  chars. 

In  string 

char,  string,  with 
padding  if  needed 
LIT 

pointer  to  number  byte 
CMPWRD  or  NEGWRD 


1 word 
1 word 
1 byte 

n bytes 

1 word 
1 word 
1 word 


MEM  ( sequence  of  WRD  tests 
WRD  entry 
IFT 

pointer  past  last  WRD  entry 
<the  above  repeated  for  all 
but  the  last  WRD  entry> 

WRD  entry 


surrounded  by  parens  ): 
n words,  as  above 
1 word 
1 word 


n words 


i (.  reatures  J 
SKIP 

pointer  to  LIT  word 
feature  mask 
LIT 

pointer  to  mask 
TSTCAT  or  NEGCAT 


ui  iu 


L 'caiuicd 


1 word 
1 word 
NWRD  words 
1 word 
1 word 
1 word 


End  Of  Sentence  ( "fEOST1  )• 
[EOS] 


1 word 
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3.0  Morphology 

3.1  General 


Ultimately,  we  would  like  to  Implement  a fairly  general  morphographemlc  processor  along 
tie  lines  of  that  used  in  the  Kay  or  Winograd  systems.  The  PATRICIA  algorithm  for  lux.- 
cal  lookup  might  lend  Itself  well  to  that  process.  Also,  the  chart  representation  of  the 
sentence  would  allow  us  to  handle  the  phrase  problem  (e  g.  whether  »o  represent 
heavy  bomber  as  one  lexical  unit  or  two;  with  a chart,  you  can  do  both). 

For  the  current  contract,  however,  wo  havo  satisfied  ourselves  with  two  lesser  exten- 
sions to  the  18, W II  approach,  first.  In  lookup,  we  accept  the  hyphen  as  a legal  wo, a 
separator  In  lexical  lookup;  l.e.  If  a lexical  entry  matches  the  Input  string  up  to  the  char 
acter  before  a hyphen,  we  call  It  a success,  create  a lexical  unit  for  It.  skip  the  hyphen 
and  go  on  to  attempt  a match  for  the  string  following  the  hyphen. 

T^,C°nt!,’  !!  a *trin9  f,oosn't  m«tch  any  lexical  entry,  we  use  an  FSA  approach  to  matching 
This  will  be  the  subject  of  the  following  sections. 

3.2  The  FSA  Matching  Process 

The  idea  here  Is  to  match  the  current  word  (or  phrase)  In  the  Input  against  a set  of  pat- 
terns represented  as  a finite  state  automaton  (FSA).  Each  final  state  of  the  FSA  spec 
flea  a feature  vector  In  the  same  manner  as  a lexical  entry.  Thus,  each  pattern  found 
corresponds  to  a feature  vector,  and  a lexical  unit  Is  generated  Just  as  In  the  case  of  a 
lexical  entry  match. 

3.3  Syntax  of  FSA 


The  syntax  of  the  FSA  Is  quite  similar  to  that  of  the  ATN  grammar,  a major 
being  the  form  of  the  tests  and  the  lack  of  actions  on  the  arcs. 


differem  o 


fsa  'PATTERN#'  start-state-name  state*  'I4ENDPATTERN' 


start-state-name  ::=  state-name 


state  ’:S#'  state-name  arc* 
state-name  .:=  Word 


arc  ::=  ':A#'  test  '#=>#’  stato-namu  'ft,,'  | *:F#'  test  feature-sot 
test  character-string  | »BI  ANK* 
feature-set  ’[#'  feature*  ’#]’ 

In  this  syntax,  rather  than  having  final  states,  we  have  "final  arcs",  designated  l>\ 
starting  with  ":F"  rather  than  ":A"  as  Is  the  case  with  normal  arcs.  Thus,  when  the  t,  i 
aucceods  on  a final  arc,  the  FSA  returns  a match  indication  with  a pointer  to  the  assoc 
ated  feature  set.  The  test  is  simply  a list  of  nonblank  characters  to  be  tested  again  t 
the  current  character  In  the  string,  or  the  Word  ABLANK*  to  test  for  the  presence  oi  , 
blank  In  the  string. 

As  an  example,  the  following  FSA  will  look  for  numbers,  and  return  the  appropriat, 
feature.  Assuming  four-digit  numbers  havo  special  significance,  K will  make  a spec  . I 
check  for  them  and  return  an  indication  when  it  finds  one. 


PATTERN  NO 
:S  NO 

:A  0123456789  =>  N1  „ 
s» 

:S  N 1 

:A  0123456789  =>  N2  „ 

:F  *BLANK*  [ NUM  ] „ 

19 

:S  N2 

:A  0123466789  =>  N3  „ 

:F  ♦BLANK*  [ NUM  ] „ 

:S  N3 

:A  01234^6789  =>  N4  „ 

:F  *BLANK*  [ NUM  ] „ 

99 

:S  N4 

:A  0123456789  =>  N5  „ 

:F  *BLANK*  [ NUM  4DIGIT  ] „ 

99 

:S  N5 

:A  0123456789  =>  N6  „ 

:F  *BLANK*  [ NUM  ] „ 

ENDPATTERN 

9.4  FSA  Program  Structures 

The  FSA  Is  called  via  the  Word  "FSA,"  which  returns  either  zero  for  no  match,  or  the 
pointer  to  a feature  vector.  The  FSA  state  structures  are  much  like  the  ATN  state 
structures,  and  are  defined  within  a scope  block  named  "FSADF".  The  arc  structures  are 
as  follows: 

Normal  (:A)  arcs: 

Arc  entry  code 

Code  for  tost  - leaves  truth  value  on  stack 

Code  for  conditional  transfer  to  specified  state  or  next  arc 


Final  (:F)  arcs: 

Arc  entry  code 
Code  for  test 

Code  for  conditional  return  from  FSA  with  feature  vector 


3.6  Algorithms  for  FSA  Program  Elements 
Element  Algorithm 

FSA  Start  Set  FSAPT  from  LEXWRK,  go  to  first  state 

State  Entry  Go  to  the  first  arc 

Arc  Entry  Set  NXTARC  to  address  of  next  arc 

Test  Code  Compare  character  pointed  to  by  FSAPT  against  specified 

character(s),  return  true  or  false 


i ■ 


t 
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If  TOS  true,  advance  FSAPT,  go  to  specified  state; 

If  false,  go  through  NXTARC 

[ features  ] If  TOS  true,  return  from  FSA  with  pointer  to  feature  vector; 

If  false,  go  through  NXTARC 

End  of  State  Return  failure  (=0)  from  FSA 
3.6  Integration  with  Lexical  Lookup 

The  addition  of  the  FSA  pattern  matcher  to  lexical  lookup  has  required  some  restructur- 
ing of  the  l&W  II  lookup  process.  In  order  to  assure  that  exceptions  to  patterns  can  be 
entered  into  the  lexicon,  the  FSA  is  tried  only  when  the  current  string  has  failed  to 
match  any  lexical  entry.  Also,  to  allow  for  future  restructuring  of  the  lexicon  for  more 
power  or  greater  search  efficiency,  the  Words  used  in  lookup  have  been  redone  to  pro- 
vide greater  modularity. 

The  top  level  remains  essentially  the  same:  Initiate  the  sentence  chart,  loop,  performing 
lookups  on  each  string  in  turn  until  the  end  of  the  sentence  text  is  reached,  then  finish 
the  chart.  The  lookup  operation  first  searches  the  lexicon,  then  uses  the  FSA  if  lexical 
lookup  failed;  if  the  FSA  fails,  the  current  string  is  checked  for  period-space,  signaling 
the  end  of  the  sentence;  if  that  is  not  found,  the  process  aborts,  signaling  an  unrecog- 
nizable string. 
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4.0  Event  Representation  Language  Implementation 

4.1  General 

This  section  describes  the  Implementation  of  the  Event  Representation  Language  com- 
ponent (ERL)  of  MATRES  II,  comprising  the  template  and  event  record  data  structures 
and  the  search  and  fill  procedures  associated  with  the  templates.  The  formalism  which 
will  be  used  for  the  abstract  specification  of  both  the  data  structures  and  the  pro- 
cedures has  been  adapted  from  the  programming  language  Prolog,  which  is  described  in 
Attachment  II.  The  advantage  of  Prolog  for  our  purposes  is  twofold:  first,  It  is  a perspi- 
cuous and  powerful  language  for  the  expression  of  the  concepts  of  our  event  represen- 
tation language,  and  second,  it  admits  of  an  effective  and  reasonably  efficient  imple- 
mentation. 

We  do  not  attempt  to  implement  the  full  Prolog  programming  language;  in  particular,  we 
only  support  the  basic  representation  of  definite  clauses  and  their  evaluation  via  the 
basic  unification  and  call/backtrack  mechanism.  Thus  we  will  refer  in  the  sequel  to  an 
implementation  of  definite  clauses  rather  than  Prolog. 

The  implementation  of  definite  clause  procedures  described  here  Is  an  adaptation  of  the 
Prolog  Implementation  described  in  Warren  (1977a).  Most  differences  between  that 
implementation  and  this  are  due  to  the  difference  In  machines  and  system  environments; 
some  are  simply  due  to  the  abandonment  of  space  and  time  saving  features  that  would 
have  been  somewhat  expensive  to  Include,  or  to  generalities  not  required  for  our  appli- 
cation. 

4.2  Strategy 

Forth,  as  it  exists,  does  not  provide  much  support  for  the  compilation  of  languages  which 
differ  much  In  syntax  from  Forth  Itself  (the  ATN  language  was  designed  to  be  very  similar 
to  Forth).  The  semantics  of  the  ERL  are  such  that  It  could  not  be  represented  In  a syn- 
tax which  would  be  easy  to  compile  with  Forth.  Therefore,  we  have  taken  the  following 
approach. 

The  syntax  of  the  ERL  is  that  of  Prolog,  on  which  it  Is  based.  A compiler  translates  that 
syntax  Into  Forth  Word  definitions,  which  are  then  loaded  with  the  rest  of  MATRES  II. 
The  compiler  Itself  is  a separate  program,  written  in  SPITBOL  (a  dialect  of  SNOBOL) 
which,  with  its  recursive  pattern-matching  facilities  and  powerful  string  handling,  lends 
Itself  well  to  this  task.  The  compiler  will  be  described  In  a later  section. 

The  Interface  between  the  output  of  the  ATN  parser,  a tree  structure,  and  the  template 
matching  procedures  expressed  in  the  ERL  is  managed  by  a set  of  Words  which  convert 
the  parse  tree  Into  a literal  representation  in  the  dictionary,  as  a nested  set  of  skeleton 
literals,  representing  the  nodes  of  the  tree,  and  atoms,  representing  the  lexical  units  at 
the  leaves  of  the  tree.  The  first  compiled  ERL  predicate  is  then  invoked  with  the  result- 
ing structure  as  Its  single  argument. 

4.3  Data  and  Procedure  Structures 

4.3.1  General  The  major  structures  in  this  implementation  are  the  local  and  global 
stacks,  the  trail,  and  the  code  area.  In  the  MATRES  environment,  the  code  area,  includ- 
ing skeletons,  resides  In  the  Forth  dictionary;  for  consistency,  the  parse  tree,  which  is  a 
constant  to  the  semantic  interpreter,  is  copied  Into  this  area  also. 

4.3.2  Environment 
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4.3.2. 1 Stack  Structures  I he  local  stack  Is  maintained  on  top  of  the  dictionary  (actually, 
the  dictionary  pointer  Is  kept  pointing  above  the  stack,  since  the  area  Just  above  the 
dictionary  Is  used  by  the  Forth  outer  interpreter).  Local  variables  are  kept  on  this  stack, 
and  consist  of  "short"  (one  word)  locations,  pointing  to  values  In  the  corresponding 
frame  of  the  global  stack.  Thus,  the  local  stack  is  one  word  wide.  A local  frame  will 
have  the  following  fields: 

A Parent  goal's  argument  pointer 

X Parent  goal’s  local  frame  address 

VI  Parent  goal's  global  frame  address 

TR  Top  of  trail  stack  whun  parent  goal  was  Invoked 

FL  Failure  address  (if  any)  for  parent  goal 

W Local  frame  address  for  the  most  recent  choice  point  prior  to  parent  goal 

DP  Forth  dictionary  pointer  contents  (therefore  top  of  local  stack)  when  parent  goal 
was  Invoked 

NX  Top  of  global  stack  (from  NXIAVL)  when  parent  goal  was  Invoked. 

Thus,  the  first  local  variable  word  is  offset  8 words  from  the  frame  base.  Temporary 
variables  are  allocated  at  the  highest  offsets. 

The  global  stack  resides  In  the  dynamic  area  on  top  of  the  sentence  chart  (the  parse 
frames  are  discarded  after  copying  the  parse  tree),  and  contains  global  variables  and 
constructed  terms  occupying  "long"  locations  (two  words  wide).  Space  is  maintained  on 
It  and  addressing  performed  using  the  same  dynamic  space  Words  as  the  ATN  processor, 
except  for  allocation  and  deletion  from  the  stack  top,  which  Is  integrally  bound  up  with 
the  clause  control  mechanisms. 

The  trail  resides  In  the  dynamic  area,  growing  downwards  from  the  top  of  the  dynamic 
address  space,  towards  the  global  stack,  and  contains  pointers  to  variable  locations  on 
the  local  and  global  stacks. 

4.3. 2.2  Special  Registers  The  special  registers  needed  to  handle  the  environment  are 
Forth  variables.  The  following  registers  aro  used: 

V local  stack  base  for  frame  being  defined  during  unification;  top  of  local  stack  after 
unification. 

VI  same  for  global  stack. 

W global  stack  base  for  current  skeleton  being  defined  during  unification;  equal  to 
VI  at  top  level. 

W image  of  V for  frame  associated  with  last  choice  point. 

W1  Image  of  VI  for  frame  associated  with  last  choice  point. 

TR  pointer  to  the  top  of  trail  stack. 

X local  frame  base  for  current  goal. 

XI  global  frame  base  for  current  goal. 

A pointer  to  argument  list  of  current  goal. 


i 


i i 

I 
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Y global  frame  base  for  current  level  goal  skeleton,  equal  to  XI  at  top  level. 

B pointer  to  argument  list  of  current  level  skeleton  being  unified  with. 

In  addition,  the  dictionary  pointer,  DP,  is  used  as  the  pointer  to  the  top  of  the  local 


stack,  and  NXTAVL  points  to  the  the  global  stack  top. 


4.3.2. 3 Constructed  Terms  These  terms  occupy  value  cells  in  the  global  stack,  and  are 
thus  long  Items. 

undef  Is  two  zero  words. 

ref(L)  Is  a constant  zero  (0)  followed  by  L,  the  address  of  the  value  cell  refer- 

enced. 

localref(L)  is  a constant  two  (?)  followed  by  L,  the  address  of  the  local  stack  word 
referenced;  this  only  occurs  during  a pseudo-machine  instruction  execu- 
tion, and  will  be  replaced  before  the  end  of  the  instruction. 

void  Is  a constant  (4)  followed  by  anything;  as  with  "localref",  this  only 

occurs  during  an  instruction. 

atom(i)  Is  a constant  six  (6)  followed  by  I,  the  address  of  the  atom  literal. 

int(l)  Is  a constant  eight  (8)  followed  by  I,  the  value  of  the  integer. 

mol(S,F)  is  S,  the  address  of  the  skeleton  literal,  followed  by  F,  the  base  address 

of  the  associated  global  frame. 

4.3.3  Unification  Algorithms 

4.3.3. 1 Dereferencing  Dereferencing  Is  applied  to  goal  arguments  to  obtain  their 
values.  Different  algorithms  are  used  for  local  and  global  variables.  For  a global  vari- 
able, references  are  followed  to  return  the  address  of  either  a value  or  an  undef  cell. 
In  the  latter  case,  the  address  is  trailed.  For  a local,  if  the  pointer  on  the  local  stack  is 
zero,  a new  global  cell  is  obtained  and  filled  with  a “localref"  to  the  stack  word,  and  the 
cell’s  address  Is  stored  in  the  stack  word,  trailed,  and  returned;  otherwise,  the  global 
algorithm  is  used  on  the  cell  pointed  to  by  the  local  word. 

4.3.3.?  Assignment  Assignment  also  differs  between  global  and  local  variables.  For 
locals,  the  address  of  the  value  cell  Is  placed  in  the  local  stack  word.  For  globals,  the 
value  Itself  Is  placed  in  the  value  cell,  unless  ft  is  undef;  in  that  case,  the  address  is 
turned  into  a reference  and  placed  in  the  cell. 

4.3.3. 3 Trailing  Trailing  is  necessary  when  an  assignment  Is  made  to  a local  word  or 
global  cell  which  is  in  an  environment  earlier  than  the  current  one,  that  is  when  the 
address  is  less  than  the  contents  of  register  V (local)  or  VI  (global).  For  a local  assign- 
ment, the  address  is  pushed  on  the  trail  stack.  For  a global,  the  address  of  the  cell  is 
pushed  onto  the  trail  stack  after  incrementing  it  by  one  to  indicate  that  it  is  a global 
address.  Resetting  from  the  trail  consists  of  getting  the  address,  checking  it  to  see  if  it 
Is  local  or  global,  and  setting  the  global  cell  to  which  it  points  to  undef,  then  clearing  the 
local  stack  word,  if  any.  Both  steps  are  necessary  in  the  local  case  because  there  may 
be  other  references  to  the  same  global  cell,  and  the  local  word  may  point  to  a global  cell 
In  a later  environment. 

In  the  sequel,  the  trailing  algorithm  will  be  assumed  to  include  the  address  check  for  the 
need  to  trail. 
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Goal  Argument  Value 


4.3.3. 4 Unification  of  Arguments 


Local  Var 

Global  Var 

Atom 

Integer 

Molecule 

Local  Var 

asg  a to 
< 

asg  a to 
< 

asg  a to 
< 

asg  a to 
< 

asg  a to 
< 

Global  Var 

asg  < to 
a,  trail 

asg  /x  to 
< 

asg  a to 
< 

asg  a to 
< 

asg  a to 
< 

Head 

Arg 

Atom 

asg  < to 
a,  trail 

asg  < to 
■a,  trail 

test  if  eg 

FAIL 

FAIL 

Type 

Integer 

asg  < to 
a , trail 

asg  < to 
a , trail 

FAIL 

test  if  eq 

FAIL 

Skeleton 

asg  < to 
a,  trail 

asg  < to 
a,  trail 

FAIL 

FAIL 

if  tncs  =, 
unify  args 

TABLE  1.  Unification  Algorithms 

The  algorithm  used  to  unify  an  argument  of  the  clause  head  with  the  corresponding  one 
in  the  goal  depends  on  the  types  of  the  two.  Table  1 gives  the  algorithms  as  a function 
of  the  types.  The  type  "var"  means  "a  variable  which  dereferences  to  undef."  Ihe 
notation  "a"  means  the  goal  argument;  ">"  means  the  head  argument.  Thus  "asg  a to 
<M  means  to  assign  the  goal  argument  to  the  head  argument.  The  algorithm  for  void  vari- 
ables is  not  shown  here;  nothing  is  compiled  for  a void  head  term,  and  a void  goal  term 
unifies  successfully  with  any  head  type. 

In  Table  1,  the  rows  represent  the  "instructions"  to  be  compiled  for  each  type  of  argu- 
ment; that  is,  the  form  of  an  instruction  is  generally  as  follows:  "dereference  the 
corresponding  goal  argument,  test  its  type,  and  perform  the  appropriate  operation". 

4.3.4  Compilation  of  Clauses  As  in  [1],  the  target  language  of  compilation  consists  of 
the  "Instructions"  of  a psoudo-machlne;  these  instructions  will  be  described  below.  In 
this  implementation,  they  conespond  to  Forth  Words  which  interpret  them. 

Each  clause  is  compiled  into  code  for  the  head  clause,  a neck  instruction,  calls  and  argu- 
ments for  the  body,  and  a foot  instruction  at  the  end.  Also,  for  each  predicate  of  a 
given  arity,  there  is  a procedure  consisting  of  an  "enter"  followed  by  "try"  calls  on  each 
clause  In  which  it  appears,  in  the  order  of  appearance;  the  last  "try"  is  actually  a 
"trylast". 

Unlike  [1],  skeletons  in  arguments  of  both  the  head  and  body  of  a clause  are  compiled  to 
all  levels,  and  have  a duai  representation:  one,  the  "goal  code",  consists  of  •»  list  of 
Instructions,  one  for  each  argument,  which  allow  accessing  the  values  of  the  arguments. 
The  other,  called  here  the  "match  code",  consists  of  instructions  to  do  the  work  of  unifi- 
cation. Thus,  in  general,  to  unify  two  skeletons,  the  match  code  of  one  will  bo  executed 
with  the  B register  set  up  to  point  to  the  goal  code  of  the  other,  the  Y register  set  up  as 
the  global  frame  base  of  the  goal  skeleton,  and  W set  up  as  the  global  frame  base  of  the 
match  skeleton 

The  code  for  the  head  of  a clause  consists  of  a "head"  Instruction,  followed  by  match 
code  for  the  arguments.  Similarly,  the  match  code  for  a skeleton  occurring  as  an 
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argument  In  a clause  consists  of  match  code  for  the  skeleton  arguments,  followed  by  a 
"return".  Match  code  In  a top-level  body  skeleton  will  only  be  executed  via  a call  from  a 
"uref”  (see  below).  For  example,  assume  that  the  clause  "membeKX.conslX.l)).'1  is 
being  unified  with  the  goal  "member(polnt(a,b),Ptlist)".  The  first  occurrence  of  X will 
unify  with  the  skeleton  "polnt(a,b)",  and  the  second  occurrence  of  X will  cause  the 
match  code  for  that  skeleton  to  be  called  to  unify  with  the  first  element  of  "Ptlist". 

The  following  subsections  give  the  instructions  used  in  the  goal  code  and  the  match 

code. 

4.3.4. 1 Goal  Code  Instruction  Definitions  These  are  long  items  which  occur  in  argument 
lists  of  the  body  or  in  the  goal  code  of  skeletons;  the  first  word  of  each  item  contains  u 
parameter,  and  the  second  points  to  a Word  which  accesses  an  item  of  that  type.  Thus, 
given  a pointer  to  such  an  Item,  the  appropriate  value  may  be  obtained  by  the  Forth 
phrase  "0+  0 EXEC".  During  unification,  the  current  vector  of  goal  argument  instructions 
Is  pointed  to  by  register  B. 

The  value  returned  by  the  access  Words  is  always  the  address  of  a value  cell  except  in 
the  case  of  "void".  The  second  word  of  the  item  also  serves  as  an  Indicator  of  the  type 
of  item.  The  algorithms  for  the  accessing  Words  are  described  below. 

var(l)  dereferences  the  Ith  variable  of  the  global  frame  whose  base  is  in  regis- 
ter Y;  occurs  only  In  goal  code.  I Is  compiled  as  a byte  offset  from  the 

global  frame  base. 

global(l)  dereferences  the  Ith  variable  of  the  global  frame  whose  base  is  in  regis- 

ter XI;  occurs  only  in  argument  lists.  I is  compiled  as  a byte  offset  from 
the  global  frame  base. 

local(l)  dereferences  the  Ith  variable  of  the  local  frame  whose  base  is  in  regis- 
ter X;  occurs  only  in  argument  lists.  I is  compiled  as  a byte  offset  from 

the  local  frame  base. 

void(O)  returns  the  address  of  a "void"  cell  (see  Constructed  Terms)  which 

was  initialized  at  the  bottom  of  the  global  stack. 

atom(l)  I Is  the  address  of  the  atom  literal;  the  access  Word  creates  a value 

cell  for  the  atom  on  the  global  stack  and  returns  its  address. 

int(l)  I is  tho  value  of  the  integer;  the  access  Word  creates  a value  cell  on 

the  global  stack  containing  the  integer  and  returns  its  address. 

[fn(l),...]  The  first  word  of  the  item  is  the  address  of  the  skeleton  literal.  The 

access  Word  creates  a molecule  on  the  global  stack  consisting  of  the 
skeleton  address  and  the  contents  of  the  XI  register,  and  returns  the 
address  of  the  molecule. 

4.3.4. 2 Match  Code  Instruction  Definitions  This  section  presents  the  instructions  used 
in  the  match  code  for  skeletons,  and  describes  the  algorithms  executed  by  the  instruc- 
tions. Except  as  noted,  the  instructions  are  actually  implemented  as  Words  which  take 
their  parameters  from  the  stack,  leftmost  parameter  on  TOS.  Thus  "uskel(N,S)"  would 
show  up  in  the  Forth  target  as  "S  N USKEL".  The  variable  and  argument  numbers  shown 
here  will  actually  be  adjusted  by  the  compiler  to  be  byte  offsets  from  the  appropriate 
base  register  values,  thus  avoiding  needless  run-time  computation. 
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uskel(N.S) 


uvar(N,F,l) 


uref(N,F,l) 


uatom(N.I) 


ulnt(N.I) 


init(l.J) 


localinit(l,J) 


Argument  N of  the  current  skeleton  Is  a skeleton  term,  and  S is  the 
address  of  the  corresponding  skeleton  literal.  Goal  argument  N at  the 
current  level  (based  on  register  B)  is  dereferenced.  If  the  result  is  a 
reference,  a molecule  is  formed  from  S and  the  contents  of  the  VI  regis- 
ter and  stored  in  the  referenced  cell;  the  assignment  is  trailed.  Other- 
wise, If  the  result  is  not  a molecule  or  the  functor  of  the  skeleton  is  dif- 
ferent from  that  of  S,  failure  occurs.  If  the  functors  match,  registers  B, 
Y,  VI  and  the  address  of  the  next  Instruction  are  saved  on  the  local 
stack,  and  new  values  are  set  for  B and  Y from  the  molecule,  thus 
preparing  to  match  the  arguments  of  the  goal  skeleton  against  the 
current  (sub)skeleton's  arguments.  The  matching  is  done  by  the  match 
code  of  the  skeleton  literal  at  "S". 

Argument  N of  the  current  head  skeleton  is  the  first  occurrence  of  vari- 
able I of  type  F (local  or  global).  Argument  N of  the  current  goal  skele- 
ton Is  dereferenced  and  the  result  is  assigned  to  cell  I in  the  current 
frame  of  the  "F"  stack,  unless  f is  global,  the  result  is  a reference  and 
the  goal  argument  is  local.  In  this  case,  the  reference  is  assigned  to  the 
goal  variable,  and  the  assignment  is  trailed  The  actual  implementation 
will  use  two  Words,  VJGVAR  for  globals  and  ULVAR  for  locals,  each  with 
two  parameters. 

Argument  N of  the  current  head  skeleton  Is  a subsequent  occurrence  of 
variable  I of  type  F (local  or  global).  The  value  of  the  variable  is 
obtained,  and  Its  type  is  used  to  switch  to  the  appropriate  unification 
code.  As  with  "uvar",  two  Words  will  be  used  for  the  Implementation, 
ULRE.F  and  UGRt  F.  In  the  case  where  the  value  is  a skeleton,  the  B,  Y, 
and  W registers  are  pushed  onto  the  local  stack,  and  the  match  code  for 
the  skeleton  is  executed  with  B and  Y set  from  the  goal  molecule  and  W 
set  from  the  reference  molecule. 

Argument  N of  the  current  head  skeleton  is  an  atom;  I is  the  address  of 
the  atom  literal  Argument  N of  the  current  goal  skeleton  Is  derefer- 
enced; If  it  is  a reference,  an  assignment  is  made  and  trailed,  otherwise 
failure  occurs  unless  it  is  atom  "I". 

Argument  N of  the  current  head  skeleton  is  an  integer;  I is  the  v.ilue  of 
the  Integer.  Argument  N of  the  current  goal  skeleton  is  dereferenced;  if 
It  is  a reference,  an  assignment  Is  made  and  trailed;  otherwise  failure 
occurs  unless  it  is  an  integer  with  value  "I". 

Is  used  to  set  global  variables  1 through  J-1  to  undef;  this  must  be  done 
just  before  a "neck"  instruction  for  variables  which  do  not  occur  in  the 
head,  and  thus  have  not  been  instantiated.  Similarly,  it  must  be  done 
before  a "uskel"  whose  skeleton  contains  first  instances  of  variables, 
since  the  skeleton  match  code  may  be  bypassed.  Omitted  if  no  such 
variables  exist. 

Like  "Init",  but  for  local  variables;  only  used  before  a "neck" 


4.3. 4. 3 Clause  and  PrcH.edure  Control  Instructions 


enter  Is  the  first  instruction  in  the  procedure  code  for  a predicate.  It  sets  up 

the  control  information  for  a new  environment  by  storing  the  VV.  X,  A.  VI. 
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and  TR  registers,  and  the  dictionary  pointer  and  dynamic  stack  top 
(NXTAVl),  Into  the  corresponding  fields  of  the  local  frame,  then  setting 
VV  and  W1  from  V and  VI,  respectively,  to  indicate  a choice  pom*. 

head(I.J)  is  the  first  instruction  in  the  code  for  the  head  of  a clause  having  I loc.il 

variables  and  J global  variables.  It  checks  the  two  stacks  to  see  that 
there  will  be  enough  room  for  the  variables  by  adding  1*8  words  to  the 
Forth  dictionary  and  allocating  J cells  on  the  global  stack,  then  sets  up 
the  environment  for  matching  arguments  by  setting  registers  B and  Y 
equal  to  registers  A and  XI,  respectively. 

neck  precedes  the  body  of  a non-unit  clause.  The  success  of  unification  is 

signaled  by  setting  registers  X and  XI  from  V and  VI,  and  setting  V and 
VI  to  the  top  of  their  respective  stacks. 

foot(N)  follows  the  body  of  a non-unit  clause  for  a predicate  of  arity  N.  If  regis- 

ter W Is  less  than  register  V,  indicating  a determinate  completion  of  the 
current  procedure,  the  dictionary  pointer  is  set  from  the  current  DP  field 
and  register  V is  set  from  register  X,  thus  recovering  all  local  storage 
used  during  the  procedure.  Registers  A,  X,  and  XI  are  restored  from  the 
corresponding  fields  in  the  frame  based  on  register  X,  and  control  is 
transferred  to  the  current  goal’s  continuation  (after  the  last  goal  argu- 
ment). 

neckfoot(N)  follows  the  head  of  a unit  clause,  and  is  equivalent  to  "neck,  fooi(N)", 
but  it  takes  advantage  of  the  lack  of  a body.  Register  VI  is  set  to  the 
top  of  the  global  stack  and,  If  nondetermlnate,  register  V is  set  to  the 
top  of  the  local  stack.  The  control  transfer  is  then  done. 

cut(l)  corresponds  to  an  occurrence  of  the  cut  symbol  in  the  body  of  a clause 

with  I local  variables  (excluding  temporaries).  Register  V is  set  to  the 
end  of  the  frame  based  on  X (after  setting  the  dictionary  pointer  from 
the  current  DP  field)  to  discard  the  local  frames  set  up  by  "neck". 
Registers  W and  VV1  are  set  from  the  corresponding  fields  in  the  goal 
frame,  based  on  X,  If  VV  does  not  already  point  to  an  earlier  frame  than 
X.  Trailed  addresses  which  are  greater  than  VV  (i.e.  created  since  the 
current  goal)  are  removed  from  the  trail. 

neckcut(l)  corresponds  to  a cut  occurring  as  the  first  goal  in  the  body  of  a clause. 

It  combines  the  effect  of  a "neck"  and  a "cut"  in  a straightforward  way. 

neckcutfoot(N)  corresponds  to  a cut  occurring  as  the  only  goal  in  the  body  of  a clause. 

It  Is  equivalent  to  "neck,  cut(O),  foot(N)".  Register  VI  !«s  Incremented;  if 
nondeterminate,  registers  VV  and  VV1  are  reset  and  trail  entries  are  dis- 
carded where  possible;  control  is  then  transferred  as  with  "foot". 

return  Is  the  end  of  the  match  code  for  a skeleton.  It  restores  the  B,  Y,  and  W 

registers  from  the  local  stack,  and  transfers  control  to  the  stacked 
return  address. 

fehl  corresponds  to  the  goal  "fail"  in  the  body  of  a clause,  and  causes  deep 

backtracking  Register  V is  set  equal  to  register  VV,  and  registers  VI,  A, 
and  X are  reset  from  their  corresponding  fields  based  on  register  V,  and 
XI  Is  set  from  the  VI  field  based  on  X.  The  dictionary  pointer  and 
NXTAVl  are  reset  from  the  corresponding  fields.  Trail  entries  are  popped 
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and  the  words  reset  until  the  TR  register  c jrees  with  the  TR  field  based 
on  V.  Note  that  shallow  backtracking,  which  occurs  on  a unification 
failure  in  the  head,  is  done  by  just  resetting  from  the  trail,  unless  regis- 
ters V and  VV  are  unequal,  in  which  case  deep  backtracking  must  be 
done.  Both  kinds  finish  by  transferring  to  tire  address  specified  in  the  FL 
field  of  the  current  local  frame. 

call(L)  corresponds  to  the  the  predicate  of  a goal  in  the  body  of  a clause.  L is 

the  address  of  the  procedure  code  for  the  predicate.  Register  A is  set 
to  point  to  the  instruction  following  the  call  and  control  is  transferred  to 
L. 

try(L)  Is  used  in  the  procedure  code  to  enter  a clause,  whose  code  is  at 

address  L.  The  address  of  the  FL  field  of  the  current  local  frame  is  set 
to  point  to  the  next  location  after  the  "try",  and  control  is  transferred  to 
L. 

trylast(L)  is  used  at  the  end  of  the  procedure  code  to  enter  the  last  clause. 

Registers  VV  and  VV1  are  reset  from  the  corresponding  fields  of  the 
current  local  frame,  and  control  is  transferred  to  L. 

4.3. 4. 4 Literals  Literals  in  this  interpretation  will  be  Forth  Words  with  compiler-assigned 
unique  Forth  names.  The  name  given  to  the  literal  in  the  ERL  source  (if  any)  will  be 
Stored  with  the  Word  as  a name  string,  l.e.  in  the  form  returned  by  WORD.  As  is  usual 
with  Forth,  the  addresses  returned  for  literals  will  be  the  code  address,  i.e.  the  address 
Of  the  first  word  of  the  literal  data. 

A skeleton  literal  is  a Forth  array,  the  first  word  of  which  points  to  the  Word  identifying 
the  principal  functor,  the  second  to  the  match  code,  and  the  third  to  the  goal  code. 

A functor  (or  atom)  literal  is  a Forth  array,  the  first  word  of  which  is  the  "arity"  of  the 
functor  (0  for  atoms),  and  the  rest  of  which  is  the  name  string. 

4.4  References 

[1]  David  H.  Warren,  "Implementing  PROLOG",  volumes  ; and  2,  D.A.I.  Research  Report 
Nos.  39  and  40,  Department  of  Artificial  Intelligence,  University  of  Edinburgh,  May 
19/7 


5.0  Event  Representation  Language  Compiler 

6.1  Strategy 

The  compiler  is  implemented  in  PDP-1 1 SPITBOL,  using  the  compiler  techniques  describ  ed 
in  James  Gimpel’s  book  "Algorithms  in  SN0B0L4",  Section  18.4,  to  reiate  the  sytuax  and 
semantics.  Familiarity  with  these  will  be  assumed  here.  The  compiler  processes  a 
clause  at  a time,  outputting  Forth  code  for  the  clause  and  adding  to  the  procedure  code 
for  the  principal  functor  of  the  clause.  At  the  end  of  the  input  file,  the  procedure  code 
for  all  predicates  is  output. 

Due  to  space  limitations  in  PDP-1 1 SPITBOL,  the  compiler  has  to  be  broken  into  sections; 
we  chose  to  make  two  programs:  the  first  pass,  which  analyzes  the  syntax  and  accumu- 
lates information  on  the  variables,  and  the  second  pass,  which  produces  the  code.  Pass 
1 produces  a file  called  "TEMPLATE. INT",  which  is  read  by  Pass  2 and  processed  to  pro- 
duce the  final  output,  called  "TEMPLATE. 4TH".  The  input  to  Pass  1 is  called 
"TEMPLATE.ERL". 

6.2  Internal  Data  Structures 

The  major  data  structures  in  the  compiler  occur  in  Pass  2.  These  are  as  follows: 

IDT  Is  a table  of  identifiers  of  atoms  and  functors.  Each  entry  in  the  table  is 

indexed  by  a string  of  ‘he  form  "name  arity",  and  its  value  is  the  Forth  name 
by  which  the  atom  or  functor  will  be  referenced.  The  table  is  initialized  with 
names  which  have  "special"  Forth  names;  the  usual  Forth  name  is  generated 
by  the  function  TIO  and  is  of  form  "Fn",  where  "n"  is  an  integer. 

PREDT  is  a table  whose  entries  are  indexed  by  the  Forth  name  of  a functor,  and 
whose  values  are  strings  containing  the  procedure  code  for  the  functors. 

PREDN  is  a table  indexed  like  PREDT,  but  whose  values  are  the  Forth  procedure 
names  corresponding  to  the  functor  names. 

PREDLST  is  a list  of  the  Forth  functor  names  of  functors  encountered  during  compiling; 

this  is  used  at  the  end  of  compilation  to  list  the  predicates  whose  procedure 
code  Is  to  be  output. 

VARL  is  a list  of  the  variables  in  a clause;  each  entry  in  the  list  is  a string  of  the 
form  "v  <name>"  (e.g  "vX"  for  a variable  named  X).  Each  such  string  is  the 
name  of  a VAR_REC  structure  containing  the  number  of  occurrences  of  the 
variable,  whether  it  is  global  or  local,  and  its  offset  from  the  base  of  its  stack. 

6.3  Pass  1 

The  main  program  consists  of  a loop  which  reads  and  compiles  a clause,  going  to  the 
label  EOIN  at  end-of-file  on  input,  which  currently  just  terminates  the  program.  Each  line 
of  the  clause  is  read  and  any  blanks  removed  (currently  a small  problem;  any  blanks  In  a 
string  literal  will  also  be  removed).  It  is  appended  to  the  rest  of  the  clause  in  string 
STMT,  and  the  string  FS,  which  was  set  during  input  pattern  matching,  checked.  If  a ter- 
minating period  was  encountered,  it  will  be  in  FS,  and  the  clause  will  be  complete.  Oth- 
erwise, another  line  is  read  at  RDLP.  The  completed  clause  has  a blank  appended  to 
match  the  pattern  FULL_ST0P,  and  it  is  output  as  a comment  (this  comment  was  origi- 
nally to  have  been  passed  through  Pass  2 into  the  Forth  code,  but  it  caused  problems 
and  so  was  dropped). 


The  pattern  CLAUSE  , which  contains  the  syntax  of  the  ERL  In  SNOBOl -executable  form, 
Is  passed  against  the  clause  twice;  first  with  the  variable  VAROUT  set  to  output  variable 
Information  from  the  semantic  routine  P1_VAR,  and  second  with  CMDOUT  set  to  output 
semantic  routine  names  and  the  values  of  strings  found  during  parsing  (variable  names, 
atoms,  etc.).  Aftei  the  first  pass,  a null  line  is  output  to  delimit  the  variable  information. 
Each  semantic  routine  In  Pass  1 has  a corresponding  routine  of  the  same  namo  In  Pass 
except  for  the  prefix  "Pn_".  The  semantic  routine  dispatching  code  at  "S  " outputs 
the  routine  names.  The  semantic  routines  themselves  have  only  to  maintain  the  term 
nesting  level  (to  allow  labeling  variable  occurrences  as  local  or  global)  and  to  output 
parsed  strings  as  found  and  pushed  during  the  pattern  match. 

6.4  Pass  2 

5.4.7  Main  Program  The  main  program  here  reads  and  discards  the  line  containing  the 
clause  text,  going  to  EOIN  if  an  end-of-flle  is  present.  Next,  the  vaiiable  information  Is 
read,  and  the  list  VARt  Is  built  and  the  count  of  global  variables  NGLOB  and  total  vati 
ables  NVAR  Is  made  by  the  loop  from  VAR  to  EOVAR.  Some  complication  of  this  code  is 
caused  by  the  fact  that  a given  occurrence  of  a global  variable  may  or  may  not  bo  glo- 
bal. 

The  null  line  after  the  last  variable  occurrence  In  the  input  causes  a pattern  match 
failure  that  causes  actual  clause  compilation  to  begin.  This  is  done  by  simply  reading  the 
Input  line  and  calling  the  semantic  dispatch  function  "S_",  which  will  transfer  to  the 
routine  named  by  the  input  line.  The  variable  DONE  Is  used  as  a terminating  condition,  it 
Is  set  null  at  the  beginning  and  non-null  by  the  routine  P2_E0Cl,  which  Is  called  at  the 
end  of  a clause.  After  compiling  the  clause,  the  variable  list  and  each  variable  name’s 
contents  must  be  deleted  to  prepare  for  compiling  the  next  clause;  this  Is  done  by  the 
loop  at  EMPTY.  Finally,  when  all  clauses  have  been  processed,  control  comes  to  LOIN, 
Where  the  list  PREDLST  is  read  and  the  procedure  code  output. 

5.4.2  Semantic  Routines  The  major  semantic  routines  are  covered  here.  To  see  the 
order  In  which  they  are  called,  and  what  inputs  are  passed  to  them,  examlno  the  syntax 
pattern  In  Pass  1.  Each  string  picked  up  by  a PUSH()“  there  is  output  by  the 
appropriate  routine,  and  thus  Is  available  to  a Pass  2 routine  by  simply  reading  the  Input 
Routines  pass  Information  to  each  other  on  the  stack  via  PUSH  and  POP,  usually  using 
the  structure  FORIH,  which  has  three  components:  a string  comprising  the  match  code 
for  an  element,  a string  comprising  the  goal  code,  and  a null  string  unless  the  element  is 
a variable,  In  which  case  It  Is  the  variable's  offset  (this  is  used  by  1 1611  and  SKI  IF. 
below). 

The  routines  are  listed  and  described  here  by  name,  with  the  “P2_"  prefix  omitted. 

VAR  Is  triggered  by  a variable  occurrence;  the  variable  name  Is  read  and  its  inter- 

nal name  (i.e.  beginning  with  "v")  Is  assigned  to  T2.  If  it  is  the  first 
occurrence  of  the  variable,  OFFSET  of  the  corresopndlng  VAR  RFC  has  not 
been  set.  In  this  case,  we  first  determine  If  the  variable  occurs  more  than 
once;  If  not,  it  Is  a void  variable,  and  we  go  to  V17VAR  to  push  the  appropriate 
structure.  If  so,  we  set  Its  offset  from  one  of  LOFF  or  GOFF,  and  update  that 
Item  (these  offsets  are  Initialized  by  INI,  and  Incremented  fry  the  appropriate 
one  of  TINC  or  GINC).  Finally,  we  push  the  variable  FORIH  structure,  including 
the  Just  assigned  offset. 

ATOM  is  triggered  by  the  occurrence  of  an  atom;  it  Is  only  nocossary  to  get  the 
atom  string,  got  a Forth  namo  for  It  via  TUT,  and  push  the  structure  for  It. 
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Is  callad  at  the  end  of  u list  occurrence.  The  stack  will  contain  the  elements 
of  the  list,  with  the  top  element  being  the  structure  for  a "nil"  atom  or  what- 
ever term  was  preceded  by  £l„CT  will  be  set  to  the  number  of  ele- 

ments, and  NEST  will  be  one  greater  than  its  value  outside  the  list.  The  item 
HI1  will  be  set  from  the  of  (set  of  the  structure  at  the  top  of  the  stuck,  only  o' 
It  currently  Is  null;  101  will  bo  set  from  the  offset  only  if  the  offset  is  not 
empty.  Both  here  and  In  SKELf,  HI1  an  f 101  will  be  set  this  way  each  time  a 
structure  Is  taken  from  the  stack;  thus,  LOI  will  contain  the  lowest  variable 
offset  seen  so  far,  and  HI1  the  highest  (this  depends  on  the  fact  that  'he 
offsets  increase  from  "right  to  left"  in  the  clause;  also,  since  only  global  vari- 
ables occur  In  these  structures,  the  offsets  will  be  global).  The  goal  and 
match  codes  of  the  top  two  stack  structures  are  concatenated  and  output, 
and  a CONS  literal  is  output  to  reference  them.  This  literal  represents  the 
end  of  the  list.  Next,  a loop  indexed  by  EL__CT  is  performed,  getting  the  next 
structure  from  the  stack  and  building  a CONS  literal  from  it  and  the  name  of 
the  CONS  literal  just  built  In  this  way  the  list  is  built  up  as  a nest  of  CONSes. 
At  tire  end  of  the  loop,  a skeleton  FORTH  structure  which  contains  the  name  of 
the  top-level  CONS  Is  pushed  on  the  stack.  If  HI1  Is  not  null,  and  NEST  is  one, 
indicating  that  the  list  is  a top-level  argument  in  the  clause,  an  INI T instruc- 
tion is  prefixed  to  the  match  code,  and  Mil  Is  set  null.  This  assures  that,  dur- 
ing unification,  variable-  with  initial  occurrences  In  the  list  will  be  ret  to 
undef . 

SKELF  is  called  at  the  end  of  a complex  term  occurrence.  The  Item  ARGNO  will  he 
set  to  (number  of  arguments  - 1)  times  4,  this  since  ARGNO  is  used  during 
argument  processing  as  the  current  argument  offset.  The  stack  will  contain 
the  arguments,  last  one  on  top,  with  the  value  of  ARGNO  outside  the  term 
below  them,  and  the  functor  name  below  that.  A loop  indexed  by  the  number 
of  arguments  is  performed,  concatenating  the  match  and  goal  code  of  the 
arguments,  and  setting  HI1  and  LOI  as  described  under  LISTF.  If  NEST  is 
zero,  Indicating  that  the  term  is  at  the  top  level,  the  number  of  arguments  and 
the  code  structure  are  pushed  back  onto  the  stack  to  be  dealt  with  by 
FIN_HEAD  (see  below).  Otherwise,  the  goal  and  match  code  are  output  fol- 
lowed by  a skeleton  literal  pointing  to  them,  and  a code  structure  for  that 
literal  pushed  onto  tho  stack  (as  in  LISTF,  including  an  INI T if  appropriate). 

GOAL  handles  a term  at  the  top  level  in  the  body,  and  expects  what  SKI  I F leaves 
at  NEST  level  0.  It  picks  the  goal  code  out  of  the  structure  on  the  stack  top, 
changes  occurrences  of  "VARACCLSS"  io  "GLOBALACCESS",  and  appends  a 
call  to  the  procedure  name  of  the  functor  to  the  clause  code  (In  item  Cl  OUT), 
with  the  goal  code  as  the  argument  list  of  the  call. 

5.4.3  Auxiliary  Functions 

FIN_HEAD  is  called  by  routines  which  occur  at  the  end  of  a clause  head  to  compile  the 
necessary  code.  It  assumes  that  the  stack  contains  what  SKI  I F leaves  for 
the  top  level.  It  picks  up  tho  match  code  from  the  top  stack  t 1 intent  anil 
gets  a Forth  name  for  the  functor  from  TID.  It  gets  a new  clause  name  and 
appends  It  to  CLOUT  as  the  Forth  Word  name  for  the  clause,  then  adds  a 
"TRY"  of  that  clause  to  the  procedure  code  of  the  functor.  Next,  a "HEAD"  is 
added  to  the  clause  code,  using  NVAR  and  NGLOB  to  compute  its  arguments, 
followed  by  the  mutch  code.  Finally,  "INIT"  and  "lOCAMNIl"  instructions  are 
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added  as  necessary  (LOFF  and  GOFF  indicate  how  many  variables  havo 
occurred  In  the  head,  and  thus  how  many  have  their  first  occurrence  In  the 
body  and  need  to  be  set  to  undef). 

EMIT  is  used  to  output  Forth  code;  It  is  necessary  because  Forth  restricts  Its  input 
lines  to  80  characters.  It  uses  the  loop  at  EMIT_1  along  with  the  function 
DEC  to  find  the  longest  string  less  than  81  characters  that  is  immediately  fol- 
lowed by  a blank,  so  that  a Word  doesn’t  get  split.  Thus  each  string  sent  to 
EMIT  gets  output  as  one  or  more  lines  with  no  Words  split  between  lines. 

TID  Is  used  to  produce  a unique  Forth  name  for  atoms  and  functors.  Its  arguments 

are  the  letter  "A"  or  "F",  depending  on  whether  an  atom  or  functor  Is  being 
Input,  the  source  name  string,  and  an  integer  giving  the  arlty  of  the  functor 
(or  zero  for  atoms).  It  concatenates  the  name  string  and  the  arlty  to  make 
and  index  to  IDT;  if  there  is  an  entry,  it  returns  Its  value,  which  is  the  forth 
name.  Otherwise,  it  makes  a new  Forth  name,  enters  It  into  IDT,  outputs  a 
"FNLIT"  associating  the  Forth  name  with  the  input  name  string,  and  (if  it  Is  a 
functor)  sets  up  the  procedure  for  the  functor,  outputting  a "RECURS"  defini- 
tion of  the  Forth  procedure  name  to  be  referenced  by  CALls,  starting  the  pro- 
cedure code,  and  adding  the  name  to  PREDLST. 

EMITPR  is  called  to  output  the  procedure  code  for  a functor.  It  converts  the  last 
"TRY"  in  the  code  to  a "TRYLAST";  if  this  fails,  there  have  been  no  clauses 
encountered  for  this  functor,  and  EMITPR  gives  up.  Otherwise,  it  outputs  the 
completed  code. 

6.6  Limitations 

This  compiler  was  produced  In  haste,  and  had  to  be  "programmed  around"  some  bugs  in 
SPITBOL;  thus,  it  has  some  shortcomings.  As  mentioned  above,  blanks  in  string  literals 
are  rudely  squeezed  out;  also,  the  semantics  will  not  properly  handle  an  atom  (i.e.  0- 
arlty  functor)  as  a top-level  term.  EMITPR  should  probably  emit  a "fall"  for  a functor 
with  no  defining  clauses.  Since  we  were  dealing  with  a limited  subset  of  PROLOG,  no 
attempt  was  made  to  allow  some  of  the  nice  features  of  that  language  such  as  number 
expressions,  infix  functors,  parentheses  and  semicolons  in  the  body,  etc. 
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6.0  Glossary  of  Lexical  and  ATN  Words 

6.1  Dynamic  Storage  accessing  Words 

DYNBAS  is  a constant  - the  base  block  number  for  pointers  to  dynamic  storage. 

NXTAVL  is  a pointer  to  the  next  available  byte  of  storage. 

GTNEW  (\GTNEW)  allocates  storage,  C(TOS)  words  (bytes)  long  (up  to  1C24  bytes), 
returns  a pointer  to  the  start  (will  see  that  storage  lies  within  a FORTH  block 
and  update  NXTAVL). 

TRUNC  truncates  dynamic  storage  at  the  pointer  on  TOS. 

D0  (\D@)  returns  the  word  (byte)  pointed  to  by  the  pointer  on  fOS. 

DS+  (\D@+)  operates  like  DO  (\D@),  but  returns  a pointer  to  the  next  word  (byte)  above 
the  retrieved  value. 

0+  (\D+)  increments  the  pointer  on  20S  by  C(TOS)  words  (bytes). 

D!  (\D!)  stores  the  word  (byte)  on  20S  at  the  location  pointed  to  by  TOS. 

D!+  (\D!+)  operates  like  D!  (\U!),  but  returns  a pointer  to  the  next  word  (byte). 

DOSET  sets  the  word  pointed  to  bv  TOS  to  zero. 

DDMOVE  moves  C(TOS)  words  from  the  location  pointed  to  by  30S  to  that  pointed  to  by 
20S  (i.e.  "from  to  length  DDMOVE"). 

DAMOVE  (ADMOVE)  is  like  DDMOVE,  but  moves  from  (to)  dynamic  storage  to  (from)  main 
memory  (e.g.  dictionary,  stack). 

\DDMOVE,  \D AMOVE,  \ADMOVE  are  byte  equivalents  of  the  above. 

DTOA  produces  a main  memory  address  from  a dynamic  storage  pointer  (to  be  used 
only  when  absolutely  necessary,  as  when  calling  a Word  which  needs  a regular 
address). 

6.2  Lexicon  Compiler 

The  working  data  items  are  as  follows: 

FPTR  points  to  the  "number  of  feature  vectors"  word  in  the  entry  currently  being 
defined.  This  pointer  is  used  to  increment  the  count  in  the  entry. 

ENP  points  to  the  first  word  of  the  entry  being  defined.  The  dictionary  pointer  (DP) 
Is  kept  pointing  to  the  end  of  the  entry. 

LXPTR  points  to  the  next  available  word  in  the  current  lexicon  block,  and  is  used  in 
moving  the  newly-defined  entry  into  the  block. 

FREBYT  count  of  the  number  of  free  bytes  left  in  the  current  lexicon  block.  This  is  kept 
consistent  with  LXPTR. 

CRMASKan  NWRD-word  array  which  contains  the  feature  vector  (or  mask)  which  is 
Currently  being  built  for  the  entry.  During  the  definition  of  the  features,  it  con- 
tains the  value  for  the  feature  next  to  he  defined. 

The  operational  Words  in  the  compiler  are  as  follows: 
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LEXICON  initializes  CRMASK  for  the  first  feature  definition,  and  starts  a scope  block  for 
feature  Words,  to  avoid  possible  conflict  between  feature  names  and  program 
names. 

FEATURE  defines  a Word  which,  when  used,  will  "or"  its  value  into  CRMASK.  The  value  of 
the  Word  is  taken  from  the  current  value  of  CRMASK;  CRMASK  ts  then  shifted 
left  one  bit  to  form  the  value  for  the  next  feature. 

::  (double  colon)  sets  up  the  next  lexical  entry,  moving  In  the  string  for  the  entry  and 
setting  up  FNP,  FPTR,  and  pointing  DP  to  the  location  for  the  first  feature  vec- 
tor. 

[ clears  CRMASK  in  preparation  for  building  the  next  feature  vector  for  the  entry. 

] moves  the  feature  mask  from  CRMASK  to  the  position  pointed  to  by  DP,  then 

updates  DP  and  the  count  pointed  to  by  FPTR. 

stores  the  length  of  the  entry  in  the  count  byte  of  the  entry,  then  moves  the 
entry  into  the  block,  starting  at  the  position  specified  by  LXPTR.  First,  however. 
It  checks  FRFBYT  to  see  if  the  entry  will  fit;  if  not,  it  stores  an  end-of  block  flag 
and  sets  up  FLEX,  LXPTR,  and  FRFBYT  for  the  next  block.  In  any  case,  it 
restores  DP  to  build  the  next  entry  in  the  same  space. 

ENDLEX  stores  an  end-of-lexicon  flag  In  the  location  pointed  to  by  LXPTR,  terminates 
the  scope  block,  and  flushes  the  block  buffers. 

6.3  ATN  Processor 

0.3. 1 Context-Related  Words 

FRAMBASE  Is  the  pointer  to  the  first  word  of  the  current  state  frame.  That  word  in  turn 
contains  a pointer  to  the  first  word  of  the  previous  frame. 

REGISTER,  LIST  are  defining  words.  They  define  a word  as  a variable  containing  the 
current  offset,  then  Increment  It.  When  the  defined  word  Is  referenced,  it  will 
return  the  then  current  value  of  FRAMBASE  added  to  its  value.  REGISTER 
defines  a one-word  cell,  LIST  a two-word  llsthead. 

CUROF  Is  the  current  offset  to  the  next  defined  item  in  the  frame.  After  all  items  are 
defined,  it  gives  the  size  of  tho  basic  state  frame. 

REGOF  is  the  offset  from  the  frame  base  to  the  first  register  cell.  It  is  used  (with 
CUROF)  to  delimit  the  register  and  list  head  area. 

1STREG  is  equated  to  the  first  defined  register  offset  of  the  state  frame.  It  is  used  to 
identify  the  start  of  the  register  and  list  head  area. 

NEWFRAME,  OLDf  RAML  are  described  elsewhere. 

6.3.2  Processor  Auxiliary  Words 

SKPTO,  GOTO,  SKPS  are  used  to  effect  transfer  of  control  at  the  same  level  of  Word 
invocation  (like  a "goto",  which  FORTH  doesn't  have,  but  Is  implicit  in  the  defini- 
tion of  an  AIN)  The  type  of  transfer  depends  on  whether  the  address  given 
contains  a word  in  a COLON-type  definition  or  is  the  code  word  of  a definition. 
In  the  case  of  a code  word,  the  return  stack  should  be  left  at  the  level  of  entry 
to  the  parser,  so  SKPS  or  SKPTO  is  used  depending  on  whether  tho  current 
Word  is  In  the  parser  or  called  by  a Word  In  the  parser.  GOTO  Is  used  to 
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transfer  within  a Word  (e.g.  to  the  next  arc)  at  the  same  level  as  SKPIO  The 
actual  transfer  of  control  occurs  when  the  next  Is  executed. 
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LIT  Is  compiled  into  a definition  and,  when  called,  pushes  the  following  word  if  the 
definition  onto  the  stack. 

\COMP  compares  two  strings  of  bytes,  given  TOS=lenyth,  20S  and  3CS  having  string 
addresses.  Returns  1 if  string  20 S < string  30S,  O if  equal,  • 1 if  string  ?OS  > 
string  30S. 

PRSTNM  takes  a pointer  to  a state  Word  parameter  address,  and  prints  the  Word’s  name 
(will  actually  work  for  any  Word). 

DPRSTNM  is  a conditional  version  of  PRSTNM 

PWORD  takes  a pointer  to  a lexical  unit,  and  conditionally  prints  the  string  and  the 
address  of  the  lexical  unit  for  tracing. 

PRLEVEL  corresponds  to  the  current  nesting  level  of  the  printout  of  a structure,  and  is 
used  as  the  indentation  count  for  a line  of  printout 

PRDELTA  is  the  amount  to  increment  PRLEVEL  for  each  nesting  level. 

PTR-TYPE  takes  a ptr  and  returns  a value  depending  on  the  type  of  element  to  which  it 
points:  0 - lexical  unit,  1 - list,  2 - node. 

PRTYP  Is  like  TYPE,  but  indents  PRLEVEL  spaces  first. 

PRLEX  takes  a pointer  to  a lexical  unit  and  prints  the  value  of  the  pointer,  an  ellipsis, 
and  the  string  for  the  lexical  unit. 

PRTPTR  takes  a ptr  and  prints  the  structure  to  which  it  points,  using  PTR-TYPt  to  select 
the  appropriate  printing  Word  to  call. 

PRLIST  takes  a pointer  to  a list  head,  prints  "LIST  OP:",  increments  PRLEVEL,  calls 
PRTPTR  for  each  listel,  decrements  PRLEVEL,  and  prints  "END  LIST". 

PRNODE  takes  a pointer  to  a node,  prints  "NODE:"  and  the  label  name,  Increments 
PRLEVEL,  calls  PRTPTR  for  each  branch,  decrements  PRLEVEL,  and  prints  "END 
NODE  •. 

FINPARSE  types  out  the  structure  for  the  parsed  sentence  roturned  in  STAR,  using 
PRTPTR. 

FALPARSE  Is  called  when  the  parser  backtracks  out  of  the  initial  state,  indicating  failure 
of  the  parse;  It  simply  types  a message. 

6.3.3  M N Processor  Words  These  are  Words  which  are  compiled  into  tho  grammar 

Itself. 

ARCENT1  is  the  first  Word  executed  in  an  arc.  It  increments  ARCNO,  prints  a message, 
and  calls  NEWPRAME,  hoping  for  success. 

PSHENT  Is  called  at  on  entry  to  a PUSH  arc;  it  sets  up  the  first  frame  for  the  subnet  and 
clears  the  registers  and  lists  at  that  level,  but  does  not  make  it  current;  rather 
It  stores  Its  address  in  NIXTERAME.  This  allows  Items  to  be  sent  to  the  subnet 
via  NEXTFRAME. 

ADVLEX  takes  a pointer  to  the  "new"  current  lexical  unit  and  pops  it  into  LEX;  this  is 
done  after  the  actions  of  an  arc  so  that  LEX  refers  to  the  right  unit  for  the 
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actions. 


SETSTAR  is  called  at  the  end  of  a PUSH  arc  to  reset  STAR  from  LEX. 

STPHNT  is  called  on  state  failure  to  print  out  the  state  name. 

STFAIL  Is  called  when  the  conditions  on  an  arc  are  not  met.  It  types  a message,  calls 
OLDFRAME  to  undo  what  ARCENT1  did,  then  sets  LEX  to  the  lexical  unit  pointed 
to  by  the  alternate  pointer  of  the  current  unit.  If  this  was  the  last  (or  only) 
alternate,  LEX  is  reset  to  the  first  alternate  (by  finding  the  next  of  the  previ- 
ous) and  the  next  arc  is  made  current.  In  any  case,  the  current  arc  receives 
control. 

FNDSTATE  takes  a pointer  to  a state  name  in  the  form  required  by  ?FIND.  It  calls  ?FIND 
to  get  the  code  address  of  the  state;  it  stores  it  in  STAAT  and  returns  it  on  the 
stack.  If  ?FIND  returns  zero,  however,  a message  is  typed  and  the  parse  is 
aborted. 

POPND  is  the  last  Word  executed  for  a POP  arc.  It  gets  the  1C  and  frame  pointer  from 
RETRN,  copies  the  arc  address,  arc  number,  state  address,  and  return  informa- 
tion from  that  frame  into  the  current  one,  copies  the  registers  and  list  heads 
from  that  frame  into  the  current  one,  pops  the  TOS  value  into  STAR,  and  goes  to 
the  postactions  of  the  calling  PUSH  arc  through  the  RETRN  1C. 

JMPND  is  the  last  Word  executed  for  a JUMP  arc.  It  just  goes  to  the  state  wnose 
name  is  stored  at  the  beginning  of  the  arc. 

1T0EX,  2T0EX  are  compiled  for  the  TO  word  of  a PUSH  arc;  1TOEX  takes  a pointer  to  the 
code  word  of  the  state  to  be  "pushed"  to  and  stores  it  in  STAAT,  and  the  frame 
base  of  the  previous  frame  in  RETRN+2,  after  moving  NEXTFRAME  to  FRAMBASE, 
thus  setting  up  the  first  frame  for  the  subnet;  2TOEX  takes  the  address  of  the 
call  to  it,  increments  it  to  be  the  address  of  the  next  word  and  stores  it  into 
RETRN,  then  goes  to  the  state  specified  in  STAAT. 

CMPWRD  takes  the  address  of  a string  of  characters  on  TOS  and  the  address  of  a lexi- 
cal unit  on  20S;  it  returns  true  if  the  string  matches  the  string  pointed  to  by  the 
lexical  unit. 

GTLEX4WRD  Is  called  between  word  items  of  a MEM  list  to  get  the  lexical  unit  pointer, 
which  has  been  saved  on  the  return  stack,  back  on  tt  e parameter  stack. 

NEGWRDcalls  CMPWRD,  then  reverses  the  truth  value. 

TSTCAT  takes  a pointer  to  a feature  mask  on  TOS  and  a pointer  to  a lexical  unit  on  20S; 

and  returns  true  if  the  vector  pointed  to  by  TOS  is  a subset  of  the  vector  of  the 
lexical  unit  pointed  to  by  20S,  i.e.  for  each  bit  posif:on  of  the  former  containing 
a one,  the  corresponding  bit  position  of  the  latter  also  contains  a one. 

NEGCAT  calls  TSTCAT  and  reverses  the  truth  value. 

ENDSNT  tests  for  the  end-of-sentence  flag  (i.e.  a zero  in  the  first  word  of  the  lexical 
unit). 

♦ returns  the  contents  of  the  special  register  STAR. 

#♦1,  *-T  return  pointers  to  the  next  lexical  unit  and  the  previous  unit,  respectively, 
using  the  appropriate  pointers  of  the  lexical  unit  pointed  to  by  LEX. 
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ADV  (RE  1)  sots  1 1 X to  tho  next  (previous)  lexical  unit 
SE  I R simply  stores  the  value  in  tho  item. 

GETR  returns  the  value  of  the  Item 


l ABIl  is  used  to  declare  a node  label,  it  takes  a value  on  the  stack  wlrch  i ; the 
number  ot  branches  tor  a node  of  that  type. 

NOPE  makes  a node  on  top  of  the  current  frame  and  returns  a pointer  to  it. 

ADOl  1ST  makes  a new  listol  on  top  of  tho  current  frame  and  link  it  to  the  front  o<  th. 

list. 

St  Nl)R  stores  tho  value  into  the  register  location  in  the  next  frame 

St  NDI  moves  the  list  head  from  the  current  frame  into  the  next  frame. 

RETR  restores  the  value  ot  the  register  into  the  current  frame  from  the  previous  one. 

RE  It  restores  the  value  of  the  list  into  the  current  frame  troni  the  previous  one. 

DEFPARSt  Is  used  to  define  PARSE;  the  variable  contents  ot  PARSi  are  set  to  point  to 
the  Initial  state  of  the  grammar.  PARSE,  when  called,  makes  tho  U.t  r,c...  e 
scope  block  visible,  uses  NtWtRAMF  to  set  up  the  initial  state  frame  as  a 
pseudo-state,  then  clears  it  and  filis  it.  selected  fields  LEX  points  to  the 
lexical  unit,  RLTRN  points  to  I INPAKSE  and  ARC  to  EALPARSL.  thus,  when  the 
top-level  POP  is  done,  I INPARSl  will  receive  control;  when  backtracking  out  of 
the  initial  state,  EALPARSt  wiit  be  the  "arc"  that  is  tiled  Finally,  NEVVE RAtoiL  is 
called  again  to  set  up  the  frame  tor  the  initial  state,  and  control  is  transferred 
to  that  stato. 

6.3.4  Compiler  Au\iliary  Words 

NCOND  is  used  during  compilation  of  the  conditional  part  of  an  arc  to  count  the  number 
of  truth  values  returned  by  tests  which  are  on  the  stack  at  a given  pent  This 
is  necessary  since  e g a CA1  arc  may  have  an  additional  test  After  the  condi- 
tional It  is  set  to  -1  if  APVt  t X should  he  complied  at  the  end  of  the  actions. 

ARClYPt  is  set  to  a number  corresponding  to  the  type  ot  aic  by  the  arc  entry  words  It 
Is  used  m various  places  vvhero  arc-type-spocific  code  must  be  compiled. 

ARCIN1  is  called  by  the  arc  entry  words  with  the  arc  type  on  IOS  It  stores  the  arc 
type  In  ARCTYPt  , compiles  a zero  and  'eaves  a pointer  to  it  on  IOS  (fins  will  be 
used  to  replace  tho  2oru  with  a pomtoi  to  the  next  arc),  compiles  a reference 
to  ARCt  Nil,  and  zeroes  NCONP. 

STA1INP  compiles  the  next  Word  in  the  source  Into  the  developing  definition  preceded 
by  a skip  around  it  and  followed  by  code  to  get  a pointer  to  the  woid  and  call 
ENPSTAU 

IFT  will  use  the  word  pointed  to  by  1C  as  the  next  1C  If  TOS  is  true 

6.3.6  Compiler  Words 

GRAMMAR  stores  the  next  Word  in  the  source  stream  and  puts  a pointer  to  i*  n ''APS! 

this  will  be  the  name  of  the  first  state  \o  be  entered  by  the  parser.  It  also 
makes  the  scope  block  containing  the  feature  Words  visible,  and  slfut".  a scope 
block  tor  state  names 


FNDGRAMMAR  makes  tho  feature  scope  block  invisible  again  and  terminates  the  state 
name  scope  block. 

:S  sots  the  FORIH  compile  mode  and  enters  the  next  word  In  the  source  in  the 

FORTH  dictionary.  Tho  code  word  for  that  entry  will  point  to  the  code  following 
tho  which  will  then  be  executed  upon  entry  to  the  state.  It  pruts  a mes- 
sage for  tracing,  zeroes  ARCNO,  sets  ARC  to  point  to  the  first  arc,  then 
transfers  control  to  that  arc. 

;;  compiles  the  end-of-state  code,  a pseudo-arc  which  simply  calls  STFAIl , prints 

a message,  and  then  clears  the  I0R1H  compile  mode. 

:WRD,  :MFM,  CAT  are  arc  ontry  Words.  They  call  ARCtNT  with  their  type  codes  end 
compile  a call  to  to  supply  an  argument  for  their  associated  tests. 

:TST,  :PSH,  :POP  are  arc  entry  Words  like  the  above,  except  that  they  have  no  Implied 
test,  and  so  do  not  compile  the  call  to  ":PSH"  compiles  a call  to  PSHLNT. 

•.JUMP  is  also  an  arc  entry  Word,  but,  after  calling  ARCENT,  it  must  enter  the  following 
Word  from  the  source,  which  is  the  name  of  the  state  to  jump  to,  into  the  dic- 
tionary preceded  by  a skip  around  it. 

!!  compiles  a logical  ANT)  if  NCONO  is  greater  than  one-  it  then  compiles  an  IFT 

which  skips  around  a STFAIL.  If  the  arc  type  Is  not  a POP  or  JUMP  which  do  not 
advance  tho  lexical  pointer,  a "*♦1"  Is  compiled  and  NCONO  set  to  - 1 . If  the 
arc  Is  a PUSH,  code  is  compiled  to  set  SNDP  to  agree  with  DP,  to  ptepure  for 
possible  SENORs. 

"1  compiles  the  string  following  up  to  the  next  quote  mark  into  the  dictionary  pre- 

ceded by  a skip  around  it  and  followed  by  a LIT  call  to  pick  up  a pointer  to  the 
string. 

"2  tests  MtMFLG;  if  it’s  set,  compiles  an  IFT  followed  by  the  word  on  TOS,  and  puts 
on  TOS  the  address  where  that  word  was  stored,  then  It  compiles  a call  to 
GTLEX4WRD  to  restore  the  lexical  unit  being  tested. 

% ( -X  ) compiles  a call  to  "1,  CMPWRD  (NEGWRD),  then  M2;  than  it  Increments  NCONO. 

( sets  ML  ML  LG  for  "2,  puts  a .zero  on  TOS,  then  compiles  a call  to  SAVE  to  save 

the  pointer  to  the  lexical  unit  to  be  tested. 

) clears  MLMFLG,  resets  the  dictionary  pointer  to  remove  the  last  IFT  and 

GTEEX4WRD  compiled  by  "2,  then  follows  the  chain  of  words  following  IF  I ends; 
In  each  one,  it  stores  the  current  dictionary  location;  finally  it  increments  NCONO 
and  compiles  calls  to  UNSAVE  and  DROP  to  remove  the  saved  lexical  unit  pointer. 

AND,  OR,  NO  I compile  boolean  operations  on  the  results  of  tests  left  on  the  stack.  AND 
and  OR  also  decrement  NCOND  since  they  leave  one  less  value  on  the  stack 
than  they  find. 

[,  -[  use  tho  Word  from  the  lexicon  Compiler  to  build  the  feature  vector  into 
CRMASK. 

finishes  a CAI  test  by  copying  the  contents  of  CRMASK  into  the  dictionary  pre- 
ceded by  a skip  around  it  and  followed  by  a LIT  call  to  pick  up  a pointer  to  tho 
compiled  feature  vector;  then  it  compiles  a call  to  TSTCAT  or  NCGCM,  depend- 
ing on  the  value  of  NEGFIG;  then  it  increments  NCONO. 


[EOS]  compiles  a call  to  ENDSNF,  then  increments  NCOND. 

= > compiles  an  ADVLEX  if  NCOND  is  negative;  this  is  aone  here  rather  than  in  "!!"  so 

that  LEX  points  at  the  current  unit  during  the  actions.  If  the  arc  is  a PUSH  type, 
compiles  a call  to  SETS7AR  to  make  STAR  agree  with  IPX  again.  STATfND  is 
then  called  to  compile  the  state  finding  code,  and  SKPS  is  compiled  to  go  to  it. 

„ compiles  the  end-of-arc  code:  POPND  for  POP  arcs,  JMPND  for  JUMP  arcs;  it 

then  puts  the  address  of  the  next  available  dictionary  locution  back  into  the 
first  word  of  the  arc,  using  the  pointer  left  on  TOS  by  ARCENT. 

TO  compiles  a call  to  1 lOEX,  then  a LIT  to  pick  up  t fie  address  of  the  current  loca- 
tion In  the  dictionary,  then  a call  to  2TOFX. 

PARSE  as  defined  at  the  end  of  the  compiler  exports  the  name  PARSE  out  of  the  ATNDF 
scope. 

8.4  FSA  Morphology  Words 

6.4.7  Morphology  Processing  Words 

f SAARC  holds  the  address  of  the  first  word  of  the  current  arc  being  executed. 

FSAPI  holds  the  address  of  the  current  character  being  tested. 

MA1CH  is  the  major  Word  of  the  . SA.  On  entry.  LEXWRk  holds  the  address  of  the  l.rsl 
character  of  the  string  to  be  matched.  On  exit,  TOS  points  to  the  feature  vec- 
tor for  the  matched  string  or  zero  if  no  match;  ESAPT  holds  the  address  of  the 
first  character  past  the  matched  string,  or  the  character  on  which  the  match 
failed. 

ARCENT2  is  the  code  for  arc  entry;  it  simply  updates  ESAARC. 

TSTCHAR  takes  a pointer  to  a wordstring,  and  a character  pointed  to  by  FSAPT;  it 
returns  true  if  the  character  is  in  the  string. 

TSTFAIL  checks  10S;  if  true,  updates  FSAPT  to  the  next  character  position;  if  false, 
floes  through  FSAARC. 

6.4.2  Morphology  Compiler  Words 

PATTERN  sets  the  name  of  the  starting  state  into  MATCH  and  opens  the  nemo  scope 
PAT DEE 

ENDPATTFRN  closes  the  name  scope  PATDEF 

:S  sets  FORTH  compile  mode,  defines  the  state  name  as  a Word,  and  establishes 

state  entry  code  which  sets  FSAARC  and  goes  to  the  first  arc. 

;;  compiles  a failure  return  as  a last  (pseudo-)  arc  and  clears  compile  mode. 

TSTCMPIL  compiles  code  to  test  current  character  against  string. 

ARCENTFSA  compiles  arc  entry  code  and  calls  FSTCMPIL  to  compile  test. 

:A,  :F  each  calls  ARCENTFSA  to  establish  a new  arc,  and  set  ARCTYPE  to  0 for  a non- 
final arc,  1 for  a final  arc  (could  be  used  for  syntax  checking,  not  currently 
done). 

=>  compiles  a call  to  TSTFAIL,  followed  by  code  to  go  to  the  specified  state. 
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[•  ] compile  a call  to  TSTFA1L,  then  a call  to  return  the  address  of  the  specified 
feature  vector  as  the  result  of  MATCH 

„ compiles  the  next  arc  pointer  into  the  first  word  of  the  current  arc. 

8.6  Text  Input  and  Lexical  Lookup 

The  major  Words  here  are  GETLXT  and  MAKESENT,  which,  when  called  in  turn,  will  read  in 

the  text  of  a sentence  and  make  the  internal  representation  for  it  - a "chart"  of  lexical 

units. 

TXTP  Is  a variable  which  contains  a pointer  to  the  first  byte  of  the  sentence  text. 

TEXSTRT  sets  up  the  processing  of  the  sentence  text  by  pointing  TXTP  and  SENTP  to 
where  the  first  character  of  the  text  will  be  stored  - the  second  byte  of  the 
next  block  after  the  end  of  the  lexicon. 

TEXEIN  completes  the  text  processing  by  appending  a period  set  off  by  blanks  to  the 
text  and  storing  tho  length  of  the  text  in  the  byte  Just  preceding  the  text. 

CHKPUNC  classifies  the  character  on  TOS  - currently,  it  returns  1 for  a comma,  2 for  a 
period,  and  0 for  any  other  character. 

CHKWRD  moves  the  "word"  read  by  WORD  to  where  SENTP  points,  preceded  by  a blank, 
updates  SENTP,  then  looks  for  punctuation  at  the  end  of  the  word  with 
CHKPUNC.  On  finding  it,  CHKWRD  backs  up  SENTP  one  character  to  strip  it  off, 
then  returns  1 if  the  punctuation  was  a period. 

GETTXT  reads  in  the  text  for  a sentence  using  the  above  words. 

The  following  words  are  concerned  with  lexical  lookup. 

LEXLEN  is  a constant  giving  the  length  of  a lexical  unit. 

STRLEN  is  a variable  containing  the  length  of  the  string  found  by  lexical  lookup. 

PVLEX  is  a variable  containing  a pointer  to  the  first  alternate  unit  of  the  most  recently 
found  word  or  phrase. 

ALTLEX  is  a variable  containing  a pointer  to  the  last-built  unit,  and  is  used  to  link  alter- 
nates together. 

LEXWRK  is  a variable  containing  a pointer  to  the  current  place  In  the  sentence  text  for 
lookup  or  lexical  unit  construction. 

LEXB  is  a variable  containing  the  current  lexicon  block  number  during  lookup. 

LEXENTCK  takes  a pointer  to  an  entry  in  the  lexicon  on  TOS,  and  compares  its  string  to 
the  string  starting  at  LEXWRK,  using  the  length  of  the  lexical  string  as  the  com- 
pare length.  If  the  lexical  entry  given  is  really  the  "end-of-lexicon"  entry,  it 
returns  -1 . 

MAM  LEX  takes  a pointer  to  a feature  vector.  It  makes  a lexical  unit,  using  LEXWRK  for 
the  string  pointer  and  STRLEN  for  the  string  length,  returns  a pointer  to  the  new 
unit,  and  updates  FRAMS7RT. 

PVLINK  takes  a pointer  to  an  old  lexical  unit  and  a pointer  to  a new  unit.  It  puts  a 
pointer  to  the  new  unit  in  the  "next"  link  of  each  alternate  of  the  old  unit,  and  a 
pointer  to  the  old  unit  in  the  "previous"  link  of  the  new. 


ALTLINK  takes  a pointer  to  an  old  lexical  unit  and  a pointer  to  a new  unit.  It  puts  the 
pointer  to  the  new  unit  in  the  "alternate"  link  of  the  old. 

MAKLEXUNT  takes  a pointer  to  a lexical  entry,  and  makes  the  lexical  umt(s)  correspond- 
ing to  the  entry.  It  makes  the  first  alternate  and  links  it  as  the  next  unit  *o 
each  alternate  of  the  previous,  then  makes  and  links  the  remaining  alternates  (if 
any).  It  then  updates  LEXWRis. 

MAKMATCHUNI  makes  a lexical  unit  for  the  string  found  by  the  FSA,  computing  the  string 
length  from  the  difference  between  FSAPT  and  LEXWRK  (less  one  to  account  for 
the  terminating  delimiter  assumed  to  have  been  seen  by  the  ESA).  Its  argument 
Is  the  feature  vector  pointer  returned  from  the  ESA. 

NEXTLEXENT  takes  a pointer  to  an  entry  in  the  lexicon  and  returns  a pointer  to  the  next 
entry,  advancing  to  the  next  block  of  the  lexicon  if  necessary. 

LXLOOKUP  searches  for  a lexical  entry  to  match  the  text  string  starting  at  LEXWRK, 
using  LEXENTCK  and  NEXTIEXI  NI.  If  found,  it  makes  a lexical  entry  tor  it  using 
MAKIEXUNT  and  returns  True.  If  not  found,  it  returns  False. 

MATCFILOOKUP  uses  the  FSA  to  attempt  a match  for  the  current  string.  If  successful,  it 
makes  a lexical  entry  using  MAKMATCFIUNT  and  returns  True,  otherwise  it 
returns  False. 

BOMB  is  used  by  LOOKUP  to  print  the  initial  segment  of  the  current  string  and  abort 
the  processing  cfter  both  the  lexical  lookup  and  the  FSA  fail  to  match  the 
current  string. 

LOOKUP  attempts  to  find  an  interpretation  of  the  current  string  as  a word  or  phrase  by 
first  calling  1 XLOOKUP  and,  if  that  fails,  MATCFILOOKUP.  If  both  fail,  it  chocks  for 
the  end  of  the  sentence  ( a period,  set  off  by  blanks).  If  the  string  is  matched 
and  a lexical  unit  made,  LOOKUP  returns  True.  If  the  end  of  the  sentence  is 
detected,  if  returns  False.  If  neither,  it  calls  BOMB  to  inform  the  operator  and 
terminate  processing  for  the  "sentence". 

SENSTRT  sets  up  the  lexical  lookup  and  lexical  unit  construction  by  pointing  LFXWRK  to 
the  start  of  the  text  and  makes  a dummy  lexical  unit  to  start  the  sentence 
chart;  this  is  needed  by  STFAIL  to  recover  the  first  alternate  of  tire  first  real 
unit  in  the  sentence. 

SENFIN  completes  the  sentence  chart  construction  by  making  a lexical  unit  with  a zero 
string  address  and  length  and  linking  it  in;  it  also  sets  FRAMSTART  to  the  next 
available  dynamic  location. 

MAKESENT  makes  the  list  of  lexical  units  for  the  sentence  by  applying  LOOKUP  until  it 
reports  False. 


7.0  Glossary  of  ERL  Target  Machine  Words 

7.1  Trail  Management  Words 

LTRAIL  takes  a pointer  to  a local  stack  word;  makes  an  entry  on  the  trail  if  necessary. 

GTRAIL  takes  a pointer  to  a global  stack  cell;  makes  an  entry  on  the  trail  if  necessary. 

EOTRAIL  is  called  during  a "cut"  operation  to  remove  from  the  trail  those  entries  which 
point  into  a stack  frame  which  is  being  discarded. 

UNTRAIL  resets  trailed  locations  and  pops  the  trail  stack  as  described  in  the  design 
document. 

7.2  New  Global  Stack  Management  Words 

GTNEW  and  its  byte  equivalent  check  that  the  requested  space  can  be  used  without 
running  into  the  trail  stack;  they  take  and  return  the  same  information  as  their  parse 
namesakes. 

7.3  Clause  and  Procedure  Control  Instructions 

FNTER,  HEAD,  NECK,  FOOT,  NECKFOOT,  CUT,  NECKCUT,  NECKCUTFOOT,  RETURN,  FEHL,  FAIL, 
CALL,  TRY,  and  TRYLAST  all  implement  the  instructions  as  presented  in  the  design  docu- 
ment in  the  straightforward  way.  In  all  cases,  the  first  argument  is  on  TOS  and  the 
second,  if  present,  is  on  20S.  FAIL  implements  shallow  backtracking,  and  is  called  only 
from  unification  instructions  at  the  instruction  level  (i.e.  the  return  stack  must  be  at  that 
level).  BACKVV  does  most  of  a TRYLAST  for  ERL  primitives. 


7.4  Dereferencing  and  Goal  Code  Words 

GDEREF  takes  a pointer  to  a cell  on  the  global  stack  and  dereferences  it. 

LDEREF  takes  a pointer  to  a word  on  the  local  stack  and  dereferences  it,  creating  a 
new  undef  cell  if  necessary. 


VARACCESS  is  the  access  Word  for  skeleton  variables. 

GLOBALACCESS  is  the  access  Word  for  global  goal  variables. 

LOCALACCESS  is  the  access  Word  for  local  goal  variables. 

VOIDACCESS  is  the  access  Word  for  void  variables. 

ATOMACCESS  is  the  access  Word  for  atom  instances. 

INTACCESS  is  the  access  Word  for  integers. 

MOLACCESS  is  the  access  Word  for  skeleton  arguments. 

7.5  Match  Code  Instructions 

GOS  is  like  a GOTO,  but  keeps  the  same  execution  level. 

SELECTOR  is  a defining  Word  for  match  code  Words.  It  sets  up  an  array  of  Word 
addresses  to  be  indexed  by  goal  code  index  values;  thus  each  Word  pointed  to 
handles  a particular  type  of  goal  argument.  When  the  defined  Word  is  exe- 
cuted, it  takes  the  argument  index  on  TOS  and  the  match  parameter(s)  on  20S 
(etc).  When  it  enters  the  selected  Word,  the  argument  index  has  been 
replaced  by  the  address  of  the  value  of  the  corresponding  goal  item.  The  Word 
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VUSKEL  called  to  unify  a skeleton  with  a goal  variable  (local  or  global).  It  .tores  a 
molecule  in  the  value  cell. 

CKFUNC  takes  two  arguments;  fails  unless  both  are  skeleton  literal  pointers  and  both 
literals  have  the  same  predicate  - returns  nothing.  UNSAVE  is  used  to  set  the 
return  stack  to  the  proper  level  before  tne  call  to  FAIL,  since  CKFL'NC  is  c .lled 
from  the  instruction  level. 

SKUSKEL  takes  pointer  to  value  cell  on  TOS,  skeleton  literal  pointer  on  20S;  checks  that 
value  is  a molecule  with  same  predicate,  sets  up  for  argument  matching  by 
pushing  the  return  address  (the  address  of  the  next  Word  after  the  call  to 
USKEL),  the  current  values  of  the  B,  Y,  and  W registers,  and  the  address  of  tne 
next  instruction,  onto  the  local  stack,  then  setting  B and  Y from  the  molecule. 
Control  is  transferred  to  the  match  code  address  taken  from  the  skeleton  literal. 
The  stacked  values  will  be  restored  by  the  RETURN  instruction  in  the  match 
code.  W is  saved  only  for  compatibility  with  the  call  from  1 OSKULREF. 

USKEL  is  defined  via  SELECTOR  to  switch  to  the  appropriate  Word  for  the  goal  value 
type  to  unify  it  with  the  skeleton. 

ASLVAR  is  a Selector  Word  called  to  unify  a local  match  variable  with  a goal  value  which 
is  an  undef,  atom,  integer,  or  molecule.  It  stores  the  address  of  the  value  in  the 
match  variable,  and  updates  NXTAVL  if  the  value  was  a new  one  built  by  an 
access  Word. 

LVLVAR  is  a Selector  Word  called  to  unify  a local  match  variable  with  a local  goal  vari- 
able, for  which  a "localref"  has  been  returned.  It  changes  the  "localref"  to  an 
undef  and  stores  the  address  of  that  cell  in  the  match  variable. 

ULVAR  is  the  instruction  for  a local  match  variable,  defined  via  SELECTOR  to  switch  to 
the  appropriate  Word  for  the  goal  value  type  to  unify  with  the  variable. 

LVGVAR  is  a Selector  Word  called  to  unify  a global  match  variaoie  with  a local  goal  vari- 
able by  putting  the  address  of  the  global  variable  cell  in  the  local  variable  word 
and  discarding  the  localref  cell  (the  dereferencing  has  already  trailed  the  local 
variable),  and  setting  the  global  cell  to  "undef". 

GVGVAR  is  a Selector  Word  called  to  unify  a global  match  variable  with  a global  goal  vari- 
able by  putting  a reference  to  the  goal  variable  cell  in  the  match  variable  cell. 

ASGVAR  Is  a Selector  Word  called  to  unify  a global  match  variable  with  an  actual  value 
cell  by  copying  the  contents  of  the  value  cell  to  the  variable  cell. 

UGVAR  is  the  instruction  for  a global  match  variable,  defined  via  SEI  ECTOR  to  switch  to 
the  appropriate  Word  for  the  goal  value  type  to  unify  with  the  variable. 

LVATOM  is  a Selector  Word  called  to  unify  a match  atom  with  a local  goal  variable  by 
changing  the  "localref"  cell  to  an  atom  cell. 


i 


I 


2-34 


GVATOMis  a Selector  Word  called  to  unify  a match  atom  with  a global  variable;  it  trails 
the  global  variable  and  changes  the  "uiidef"  cell  to  an  atom  cell 

EQATOM  is  a Selector  Word  culled  to  unify  a match  atom  with  a goal  atom  by  comparing 
the  atom  values  for  equality. 

UATOM  is  the  Instruction  for  a match  atom,  defined  via  SELECTOR  to  switch  to  the 
appropriate  Word  for  the  goal  value  type  to  unify  with  the  atom 

LVINT  Is  a Selector  Word  called  to  unify  a match  integer  with  a local  goal  variable  by 
changing  the  "localref"  cell  to  an  integer  cell. 

GVINI  is  a Selector  Word  called  to  unify  a match  integer  with  a global  variable;  it  trails 
the  global  variable  and  changes  the  "undef"  cell  to  an  integer  cell. 

EQINT  is  a Selector  Word  called  to  unify  a match  integer  with  a goal  integer  by  com- 
paring the  integer  values  for  equality. 

UINT  is  the  instruction  for  a match  integer,  defined  via  SELECTOR  to  switch  to  the 
appropriate  Word  for  the  goal  value  type  to  unify  with  the  integer. 

GVUREF  is  the  code  to  unify  a goal  with  the  referenced  variable,  which  has  been  unified 
with  another  variable;  it  is  handled  via  UGV/AR  after  setting  up  the  slack. 

ATUREF  is  the  code  to  unify  a goal  with  the  referenced  variable,  which  has  been  unified 
with  an  atom;  it  Is  handled  via  UAIOM  after  setting  up  the  stack. 

INUREF  is  the  code  to  unify  a goal  with  the  referenced  variable,  which  has  been  unified 
with  an  integer;  it  is  handled  via  UINT  after  setting  up  the  stack. 

OSKUREF  is  the  code  to  unify  a skeleton,  which  is  the  value  of  the  referenced  variable, 
with  a global  goal  variable.  A molecule  is  assigned  to  the  goal  variable,  and  the 
assignment  is  trailed. 

2SKUREF  is  the  code  to  unify  a skeleton,  which  is  the  value  of  the  referenced  variable, 
with  a local  goal  variable.  A molecule  is  assigned  to  the  goal  variable. 

4SKUREF  is  the  code  to  unify  a skeleton,  which  is  the  value  of  the  referenced  variable, 
with  a void  variable.  The  stack  Is  restored. 

SFAIl  clears  the  parameter  stack  and  calls  FAIL;  It  is  called  when  an  attempt  is  made 
to  unify  a reference  skeleton  with  an  atom  or  integer. 

10SKURFF  is  the  code  to  unify  a skeleton,  which  is  the  value  of  the  referenced  variable, 
with  a goal  skeleton.  The  functors  are  compared  and,  if  they  are  equal,  the 
match  code  of  the  referenced  skeleton  is  executed,  after  saving  registers  R,  V, 
and  W on  the  local  stack,  and  setting  B and  Y from  the  goal  skeleton  a, id  W from 
the  frame  word  of  the  reference  skeleton.  The  "return"  Instruction  of  the  match 
code  will  restore  the  registers  and  return  to  the  level  that  called  "uref". 

SSKUREF  is  a Selector  Word  to  switch  to  the  appropriate  code  to  unify  the  goal  value 
type  with  the  reference  skeleton  (the  value  of  the  referenced  variable). 

SKUREF  is  the  code  to  unify  a goal  with  the  referenced  variable,  which  has  been  unilied 
with  a skeleton.  It  sets  up  the  goal  argument  index  on  TOS,  and  the  skeleton 
and  frame  words  on  ?OS  and  30S,  and  executes  SSKUREF  to  do  the  work. 


2-35 


REFTYPE  is  an  array  of  Words  used  by  ULREF  to  switch  to  the  code  to  handle  different 
value  types. 

ULREF  is  the  instruction  for  a subsequent  occurrence  of  a local  match  variable.  It 
obtains  the  value  of  the  variable,  and  switches  to  the  appropriate  Word  to  han- 
dle the  value  type,  leaving  a pointer  to  the  value  cell  on  10S  and  the  argument 
Index  on  ?OS. 

UGREF  Is  the  instruction  for  a subsequent  occurrence  of  global  match  variable.  It  uses 
GDEREF  rather  than  LDEREF  to  obtain  the  value  of  the  variable,  but  subse- 
quently operates  just  like  UlREF,  since  in  both  cases  the  value  is  a pointer  to  a 
global  cell  containing  either  a value  or  undef. 

INI T takes  a global  stack  offset  (in  bytes)  on  TOS  and  another  on  20S.  It  clears  the 
words  on  the  stack  from  that  specified  on  TOS  up  to  that  specified  on  20S. 

LOCALINIT  is  like  INI  I,  but  works  on  the  local  stack. 

7.6  ERL  Primitives 

These  Words  act  like  ERL  procedures,  but  operate  on  "lower-level"  data,  such  as  lexical 

units  and  the  output  facilities  of  FORTH.  The  ERL  compiler  recognizes  their  names  and 

compiles  them  accordingly. 

FEAT  takes  two  arguments,  and  fails  unless  the  first  is  a lexical  unit,  the  second  is  an 
atom  which  is  the  name  of  a defined  feature  ol  the  lexicon,  and  the  lexical  unit 
has  the  specified  feature. 

TYPATOM  takes  one  argument,  and  fails  if  it  is  not  an  atom.  If  it  is,  it  is  typed  on  the 
console 

TYPLEX  is  like  TYPATOM,  but  requires  its  argument  to  be  a lexical  unit. 

TYPCR  does  a FORTH  "CH"  function  to  terminate  a line. 

LEXEQ  takes  two  arguments,  and  fails  unless  the  first  is  a lexical  unit,  the  second  is  an 
atom,  and  the  string  of  the  lexical  unit  is  equal  to  the  atom  name.  This  primitive 
Is  necessary  because  FRt  -compiled  atoms  will  not  unify  with  lexical  units 
through  the  normal  process. 
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8.0  Glossary  of  GLUE  File  to  Connect  Parse  to  Templates 

8.1  Strategy 

The  "glueing"  function  is  performed  by  first  converting  the  AIN  parse  tree  tn  an  till 
skeleton  form  in  the  dictionary.  In  this  representation,  lexical  units  ate  stoied  as  atoms, 
with  the  atom  address  actually  being  the  lexical  unit  address.  I his  is  unambiguous, 
since  lexical  units  are  stored  early  In  dynamic  space,  and  thus  their  addresses  are  small 
numbers,  between  the  values  of  SEN  TP  and  FRAMSTART.  lists  are  stored  as  skeletons 
representing  terms  of  the  form  "cons(a,cons(b,...cons(i,nil)...)".  Nodes  are  stored  as 
skeleton  literals,  the  label  of  the  node  being  a functor  literal.  It  should  be  noted  that  tin- 
conversion  process  reverses  the  elements  of  a list  and  the  branches  of  a node;  since 
they  are  stored  in  reverse  order  in  the  parse  tree,  this  puts  them  back  in  the  right  order 
for  template  matching. 

Skeleton  literals  arc  built  by  allocating  an  array  in  the  dictionary  for  the  goal  code,  and 
"pushing"  the  match  code  onto  the  dictionary  after  that.  The  "build"  Words  take  a 
pointer  to  some  piece  of  the  parse  tree  and  return  a type  indicator  (0  lor  atoms,  1 for 
skeletons)  on  JOS  and  a value  (the  atom  address  or  skeleton  literal  address)  on  20S. 

8.2  Skeleton  Building  Words 

BLLEX  needs  only  to  add  the  atom  indicator  to  its  input. 

BLPTR  checks  its  input;  a zero  pointer  is  returned  as  the  atom  "nil”;  otherwise  it  calls 
BLLEX,  BLLIST,  or  BLNODE  as  indicated  by  the  return  from  PIH-JVPt. 

STPAIR  builds  goal  and  match  code  for  an  item  returned  from  a build  Word.  It  takes  the 
goal  code  address  on  TOS,  the  type  indicator  on  20S,  and  the  value  on  SOS.  It 
stores  the  match  code  using  ","  to  update  DP,  and  uses  and  updates  ARGNO  to 
put  the  argument  number  In  the  match  Instruction.  It  returns  the  next  available 
goal  address. 

Bl  NODE  builds  a skeleton  literal  for  a node.  It  calls  BLPTR  to  build  its  branches  (and 
stacks  the  returns),  then  sets  up  the  goal  code  array,  sets  ARGNO  to  0 and 
calls  STPAIR  n times  to  make  the  match  and  goal  code  for  the  node;  finally  It 
builds  the  three  skeleton  words  on  the  top  of  the  dictionary  and  returns  their 
address  and  the  skeleton  indicator. 

BIT  1ST  builds  a nested  set  of  skeleton  literals  for  a list,  it  builds  each  element  into  a 
"cons"  skeleton,  the  last  one  (first  one  built)  having  a second  argument  of  "nil". 
At  the  entry  to  the  loop,  the  pointer  to  the  current  list  element  is  on  TOS,  and 
the  return  from  the  last  element  is  on  20S  and  30S. 

8.3  Driver  Word 

This  Is  the  Word  used  to  fully  process  a sentence;  it  calls  the  Word  to  get  the  text,  do 
lexical  lookup,  and  build  the  parse  tree;  then  it  calls  Bl  PTR  with  the  contents  of  STAR  to 
convert  the  tree.  Next  it  sets  up  the  initial  environment  for  the  ERl  machine,  puts  the 
returned  address  from  BLPTR  in  the  first  argument  position,  and  calls  P001,  the  first 
compiled  predicate  of  the  compiled  ERL  program,  assuming  that  that  predicate  has  a 
defining  clause  of  the  form  "name(Tree):-body.". 
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Appendix  A - MATRES  II  Program  Listings 


1.0  Top-Level  System  Module 

( ===  =======  ====  = = = MATRES.  4TH  - Top-level  Command  File  = ====  = ==) 

: ['  135  DELIM  ! WORD  HERE  COUNT  TYPE  CR  ; 

0ATNLEX 

SLEX1C0N 

0FSA 

['  LEXICON  LOADED  . . ] 

['  COMPILING  GRAMMAR  . .] 

0 GRAMMAR 

['  LOADING  ERL  MACHINE  ..] 

0ERLM 

['  LOADING  TEMPLATES  ..] 

0 [60,  5]  TEMPLATE 
0GLUE 

['  MATRES  READY!] 


2.0  Lexical  and  ATN  Processing  Module 

( See  Matres  Glossary  document  for  descriptions  of  these  Words) 

( we  use  base)  DECIMAL 

CODE  LIT  S -)  IC  )+  MOV,  NEXT,  ( RETURN  CODE  ADDRESS;  USED  TO  COMPILE  WORDS) 

( ========================  Lexicon  Compiler  ================================  ) 

80  CONSTANT  MAXF  MAXF  16  /MOD  SWAP  0>  + CONSTANT  NWRD  0 VARIABLE  NUMF 
NWRD  ARRAY  CRMASK 

40  CONSTANT  SLEX  SLEX  VARIABLE  ELEX 

0 VARIABLE  FPTR  0 VARIABLE  ENP  1024  VARIABLE  FREBYT 

SLEX  BLOCK  VARIABLE  LXPTR 

CODE  2*=  T S )+  MOV,  S ) ROR,  T ) ROL,  S ) ROL,  NEXT, 

: FEATURE  I ARRAY  0 NWRD  2*  CRMASK  + CRMASK  DO  I § , I 2*=  2 + LOOP  DROP 

' IMMEDIATE  EXEC  NUMF  1+!  CRMASK  NWRD  MERGE  ; 

: : : WRD  2 DP  +!  WORD  HERE  1+  \@  40  = IF  41  DELIM  ! WORD  THEN 
HERE  DUP  1-  HERE  \@  DUP  SAVE  1+  \MOVE  UNSAVE  ; 

; ::  HERE  ENP  ! ::WRD  HERE  + 1+  -2  AND  DUP  OSET  DUP  FPTR  ! 2+  DP  ! ; 

SC.  [ BRACE 

: [ CRMASK  DUP  OSET  DUP  2+  NWRD  1-  MOVE  IMMEDIATE  ; 

].SC  BRACE 

: ) CRMASK  HERE  NWRD  MOVE  FPTR  0 1+!  NWRD  2*  DP  +!  ; 

: ENP  0 DUP  DP  0!  SWAP  - DUP  HERE  \!  DUP  FREBYT  0 SWAP  - DUP 

0>  IF  FREBYT  ! HERE  SWAP  LXPTR  0 SWAP  DUP  LXPTR  +!  2/  MOVE  UPDATE 
ELSE  DROP  DUP  1024  SWAP  - FREBYT  ! -1  LXPTR  0 ! ELEX  0 1+  DUP  ELE < ! 


BLOCK  OVER  OVER  ♦ LXPTR  ! HERE  SWAP  ROT  2/  MOVE  UPDATE  THEN  ; 

: LEXICON  SC*  BRACE  l 1 CRM ASK  ! [ SC.  I FEATURES  SC. V BRACE  ] OINT  ; 

: ENDLEX  LXPTR  8 OSET  FLUSH  l >. SC  FEATURES  SC. I BRACE  ] OINT 

MAXF  NUMF  8 < IF  l TOO  MANY  FEATURES  CHANGE  MAXF  AND  RECOMPILE] 
TYPE  CR  ABORT!  THEN  ; 


( Dynamic  Storage  accessing  Words  ■•»■■■■■»■••*■■«*■■«*•  ) 

0 VARIABLE  DYNBAS 
0 VARIABLE  NXTAVL 

: \GTNEW  DUP  NXTAVL  8 1023  AND  MINUS  1024  + < IF 
NXTAVL  DUP  8 ROT  ROT  +! 

ELSE 

NXTAVL  8 1023  ♦ 1024  AND  DUP  ROT  NXTAVL  ! THEN  ; 

: GTNEW  2*  \GTNEW  ; 

: TRUNC  NXTAVL  ! ; 

CODE  /UMOD  T 2 S I)  MOV,  0 CLR,  S )+  0 D1V,  S ) T MOV,  S -)  0 MOV,  NEXT, 

: GTAD  1024  /UMOD  DYNBAS  8 + BLOCK  + ; ( TAKE  POINTER,  RETURN  CORE  ADDRESS) 

: D8  GTAD  8 ; 

: \D8  GTAD  \ 8 ; 

: D+  LIT  2*  , LIT  + , IMMEDIATE  ; 

: \D+  LIT  + , IMMEDIATE  ; 

: D8  + DUP  D8  SWAP  2+  ; 

: \D§*  DUP  \D8  SWAP  U ; 

: D!  GTAD  ! UPDATE  ; 

: \D!  GTAD  \!  UPDATE  ; 

: D!  SWAP  OVER  GTAD  ! 2+  UPDATE  ; 

: \D!  ♦ SWAP  OVER  GTAD  \!  1+  UPDATE  ; 

: DOSET  GTAD  OSET  ; 

: DDMOVE  ROT  GTAD  ROT  GTAD  ROT  MOVE  UPDATE  ; 

: \ DDMOVE  ROT  GTAD  ROT  GTAD  ROT  \MOVE  UPDATE  ; 

: DAMOVE  ROT  GTAD  ROT  ROT  MOVE  ; 

: \DAMOVE  ROT  GTAD  ROT  ROT  \MOVE  ; 

: ADMOVE  ROT  ROT  GTAD  ROT  MOVE  UPDATE  ; 

: \ ADMOVE  ROT  ROT  GTAD  ROT  \MOVE  UPDATE  ; 

: DTOA  GTAD  ; 


( ======  Conditional  print  Words  for  debugging  =============== 

0 VARIABLE  DEBUG 

: DBT  DEBUG  8 IF  TYP1  ELSE  2DROP  THEN  ; 

! OB.  DEBUG  8 IF  . ELSE  DROP  THEN  ; 

: OCR  DEBUG  8 IF  CR  THEN  ; 
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( ===============  Redefinitions  of  system  Words  ==  = = 

: (.  ' ( EXEC  IMMEDIATE  ; 


( ==================  state  frame  definitions  ================== 

0  VARIABLE  FRAMSTART  0 VARIABLE  SEN'TP 

0 VARIABLE  FRAMBASE 
2 VARIABLE  CUROF 

: ITEM  2*  CUROF  0!  DUP  CUROF  +!  VARIABLE  0 FRAMBASE  0 \D+  ; 
: REGISTER  1 ITEM  ; : LIST  2 ITEM  ; 

( Basic  frame  items  - leave  in  this  order  <P0PND  assumes>) 

1 ITEM  LEX  1 ITEM  STAR  1 ITEM  ARC 

2 ITEM  RETRN  1 ITEM  ARCNO  1 ITEM  STAAT 


=============  ) 


CUROF  0 VARIABLE  REGOF  0 ITEM  1STREG 

: NEWFRAME  CUROF  0 \GTNEW  DUP  FRAMBASE  0!  DUP  ROT  D! 

1 D+  FRAMBASE  0 1 D+  CUROF  0 2/  1-  DDMOVE  ; 

: OLDFRAME  FRAMBASE  0 DUP  TRUNC  D0  FRAMBASE  ! ; 


( ==================  ATN  Processor  Auxiliary  Words  =========================  ) 

CODE  SKPTO  R ) S MOV,  S )+  TST,  NEXT, 

CODE  GOTO  R ) S ) + MOV,  NEXT, 

CODE  SKPS  R -)  S MOV,  S )+  TST,  NEXT, 

CODE  \COMP  0 S )+  MOV,  T S )+  MOV,  3 S )+  MOV, 

BEGIN,  T ) + \ 3 ) + CMP,  NE  1+  , 0 SOB, 

IFGT,  T 1 # MOV,  ELSE,  IFEQ,  T CLR,  ELSE, 

T -1  # MOV,  THEN,  THEN,  PUSH  J, 

: PRSTNM  10  - \0+  SWAP  CONVERT  COUNT  TYP1  [ |]  TYP1  4 TYP1  ; 

: DPRSTNM  DEBUG  0 IF  PRSTNM  ELSE  DROP  THEN  ; 

: PWORD  DUP  DB.  [ ..  ] DBT  D0+  SWAP  GTAD  SWAP  D0  DBT  DCR  ; 

0 VARIABLE  PRLEVEL  2 CONSTANT  PRDELTA 

: PTR-TYPE  DUP  FRAMSTART  @ < IF  DROP  0 ELSE  D0  IF  2 ELSE  1 THEN  THEN  ; 

: PRTYP  CR  t I I I II  I II  I I I II  I I I M DROP  PRLEVEL  0 TYP1  TYP1  ; 

: PRLEX  DUP  CONVERT  COUNT  PRTYP  [ ..  ] TYP1  D0+  D0  SWAP  GTAD  SWAP  TYPE  ; 

RECURS  PRTPTR  RECURS  PRLIST  RECURS  PRNODE 

: R PRTPTR  DUP  0=  IF  [ <<NIL>>]  PRTYP  DROP  ELSE  DUP 
PTR-TYPE  DUP  0=  IF  DROP  PRLEX  ELSE 
1 = IF  PRLIST  ELSE  PRNODE  THEN  THEN  THEN  ; 

: R PRLIST  [ LIST  OF:]  PRTYP  PRDELTA  PRLEVEL  +!  1 D+  D@ 

BEGIN  DUP  WHILE  D0+  SWAP  PRTPTR  D@  ENDWHILE  DROP 
PRDELTA  PRLEVEL  -!  [ END  LIST]  PRTYP  ; 

: R PRNODE  D0+  OVER  [ NODE:  ] PRTYP  PRSTNM  PRDELTA  PRLEVEL  +! 


DUP  ROT  P D + SWAP  DO  1 DP  PRTPTR  2 + LOOP  PRDFLTA  PRLEVEL  -! 
I END  NODE)  PRTVP  ; 


0 VARIABLE  PRTREE 

: FI  NP  ARSE  PRTREE  P I F CR  [ PARSE  OUTPUT:]  TYPE  CR  STAR  DP  PRTPTR  THEN 
[ SC.  I GRMDF  ] 01  NT  ; 


CODE  FALPARSE  HERE  2*  , 0 , 2 STATE  ! [ PARSE  FAILED!]  TYPE  CR  ; 


( ••■■■•••••■••uiihii  ■>■■  ATN  Processor  Words  = ) 

: ARCENT1  ARCNO  DP  1+  DUP  ARCNO  D!  I TRY  ARC  tf  ] DBT  DB. 

I . . ] DBT  NEKFRAME  ; 

0 VARIABLE  N EXTRAS E 

: PSHFNT  NEW  FRAME  1STREG  0 OVER  DI  + CUROF  P REGOF  P - \DDMOVE 

FRAN1BASE  DUP  • DP  SWAP  P!  NEXTBASF  ! FRAME  ASF  P DP  NEXTFASE  P D!  ; 

: ADVLEX  DUP  LEX  D!  STAR  D!  ; 

: SETSTAR  LEX  DP  STAR  D!  ; 

: ST PR NT  I STATE  ] DBT  ST A AT  DP  2*  DPRSTNM  ; 

: ST FA  I L [ FAILED!]  DBT  DCR  OLDFRAME 

LEX  DP  4 Dt  DP  DUP  IF  ADVLEX  ELSE  DROP  LEX  DP  3 D*  DP  2 D«  DP  ADVLEX 
ARC  DP  P ARC  D!  THEN  ARC  DP  2*  GOTO  ; 

: FNDSTATE  DUP  YFIND  DDF  0=  IF  DROP  COUNT  TYP1  [ UNDEFINED  STATE] 

TYPE  ABORT! 

ELSE  SWAP  DROP  DUP  STAAT  D!  THEN  ; 

: POPND  FRAMBASE  A D'  NEW  FRAME  FRAMBASE  P DUP  SAVE  D!  RETRN  DA  ♦ DP  FRAMBASE  ! 
ARC  UNSAVE  FRAMBASE  ! ARC  10  CUROF  A REGOF  A - ♦ \DDMOVE 
SWAP  STAR  D!  GOTO  ; 

: JMPND  ARC  DA  t)  «■  FNDSTATE  SKPTO  ; 


: 1TOEX  NEXTBASF  P FRAMBASE  ! STAAT  D!  FRAMBASE  P DP  RETRN  1 D*  D!  ; 

: 2TOEX  4 + RETRN  D!  STAAT  DP  SKPTO  ; 

: CMPWRD  SWAP  DP*  DP  3 'S  P \P  IF  DTOA  SWAP  \P  + SWAP  \COMP  0 = 

ELSE  2 DROP  0 THEN  ; 


GTLEX4WRD  UNSAVE 

DUP  SAVE 

9 

NEGWRD 

CMPWRD  0. 

1 

TSTCAT 

SWAP  5 D* 

DTOA  DUP 

NWRD  2*  * SWAT 

DO  P* 

SWAP  DUP  1 

1 P AND  - 

IF  ELSE  DROP  0 TERM  THEN 

NEGCAT 

TSTCAT  0= 

9 

ENDSNT 

DP  0=  ; 

1 
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SC.  I ACT  P F 

: • STAR  Lit!  ; : *.l  LEX  D$  2 D*  Dt»  ; : *-l  LEX  DS  3 D+  US  ; 

: ADV  *♦  1 DUP  LFX  PI  STAR  D!  ; 

: RET  * 1 PUP  LEX  t)t  STAR  D!  ; 

: SETR  LIT  PI  , IMMEDIATE  ; 

: GETR  LIT  D«  , IMMEDIATE  ; 

: LAPEL  WORD  HERE  DUP  \ ■ SWAP  DUP  12  ♦ ROT  1*  \MOVE  ENTER  , 

’ DYNBAS  2-  S LAST  S ! HERE  \S  2*  -2  AND  DP+!  ; 

: NOPE  PUP  S PUP  .V  GTNFW  PUP  SAVE  SWAP  SAVE  D!  ♦ UNSAVE 

0 DO  D!  ♦ LOOP  DROP  UN SAVE  ; 

: APPLIST  2 GTNEW  DlIP  ROT  1 D.  GTAD  t>!  ROT  ROT  Dt  ♦ P!  ; 

: SENDR  SRAMBASE  NEXTBASE  S ♦ D!  ; 

: SENPL  PUP  P<«  IV  SWAP  ROT  F RAM BASE  $ NEXTBASE  S ♦ D!  ♦ D!  ; 

: RETR  DUP  FRAME ASF  ? PUP  IV  - Hi  SWAP  P!  ; 

: RETL  DUP  FRAME  ASF  *'  DUP  DS  - DS+  DS  SWAP  ROT  D!  ♦ D!  ; 

]. SC  ACTDF 

: DEFPARSE  VARIABLE;:  NEW FRAME 

FRAMBASE  S DUP  DOSET  DUP  1 IV  CUROF  i 2/  1 UDMOVE 

SENTP  S ADV LFX  ' F 1 SPARSE  RETRN  D!  ' FALPARSE  ARC  D!  NEWFRAME 

1 SC.  V GRMDF  ] 01  NT  S FNDSTATE  SKPS  ; 

0 DEFPARSE  PARSE 


( bbbxis.  Compiler  Auxiliary  Words  ---------------  — 

0 VARIABLE  NOOND 
0 VARIABLE  ARCTYPE 

: 1 0 1 NT  STATE  t?  S AVE  STATE  OSET  01NT  UNSAVE  STATE  ! ; 

: ARCENT  ARCTYPE  ' HERE  0 , LIT  ARGENT i , NCOND  OSET  l SC.  V TSTWRD  ] 

: STATFND  LIT  SKIP  , HERE  P , PUP  WORD  6 DP  +1  HERE  SWAP  ! 2- 
LIT  LIT  , , LIT  FNDSTATE  , ; 

CODE  l FT  S ) ■*  TST,  I FFQ,  10  )♦  TST,  NEXT,  THEN, 

IC  IC  ) MOV,  NEXT, 


( omp 1 1 e r Wo  rd  s 

; GRAMMAR  WORT  HERE  ' PARSE  ! 6 DP  ♦ ! 

(SC  SS  SC  \ ATNDF  SO.  \ ACTDF  SC.  I GRMDF  ] 01 NT  ; 

: ENDGRAMMAR  [ SO.  1 FEATURES  SO.  1 ATN'PF  SC.  I ACTDF  '.SC  GRMDF  ] 01  NT 

SC.  t ATNDF 
SC. V ACTDF 

: : S 2 ST at;  DOR  ; ENTERING  STATE  J PPT  PUP  PPRSTNM 

{ AT  UNIT  ] DPT  LEX  Di  PWORD 
0 ARONO  Dl  DUP  ARC  D1  2*  GOTO  ; 

: 0 , LIT  1 PK\ , , LIT  STFAII  , STATE  OSET  IMMEDIATE  ; 


10 1 NT 


: WRD 

1 

ARGENT 

LIT  • , IMMEDIATE  ; 

: CAT 

3 

ARGENT 

LIT  » , IMMEDIATE  ; 

: TST 

4 

ARCENT 

IMMEDIATE  ; 

: PSH 

5 

ARCENT 

IMMEDIATE  LIT  PSHENT 

: POP 

6 

ARCENT 

IMMEDIATE  ; 

: JUMP 

7 

ARCENT 

LIT  SKIP  , HERE  0 , 

: MEM  2 ARGENT  LIT  * , IMMEDIATE  ; 


: NOT  0=  ; 

SC.  I TSTWRD 

: ! ! NCOND  S 1-  0>  IF  LIT  AND  , THEN  LIT  1 FT  , HERE  4 + , 

LIT  STFAIL  , ARCTYFF.  $ S < I F LIT  *+ 1 , - 1 NCOND  ! THEN 

[ SC.  I TSTWRD  ] 10 1 NT  IMMEDIATE  ; 

0 VARIABLE  MEMFLG 

: "1  LIT  SKIP  , HERE  0 , DUF  34  DELIM  ! WORD  HERE  \S  2+  -2  AND  DF  + ! 

HERE  SWAP  ! 2+  LIT  LIT  , , ; 

"2  MEMFLG  S IF  LIT  I FT  , HERE  SWAP  , LIT  GTLEX4WRD  , THEN  ; 

" "1  LIT  CMFWRD  , "2  NCOND  1+1  IMMEDIATE  ; 

"l  LIT  NEGWRD  , "2  NCOND  1+!  IMMEDIATE  ; 

: ( MEMFLG  1SET  0 LIT  SAVE  , IMMEDIATE  ; 

: ) MEMFLG  OSET  HERE  4 - DUF  DF  ! DUP 

BEGIN  SI  DUF  WHILE  HERE  SWAP  ENDWHILE  DROP 

NCOND  1 ♦!  LIT  UNSAVE  , LIT  DROP  , IMMEDIATE  ; 

: AND  NCOND  1-!  LIT  AND  , IMMEDIATE  ; 

: OR  NCOND  1-!  LIT  OR  , IMMEDIATE  ; 

0 VARIABLE  NEGFLG 

[ SC*  BRACE  t IMMEDIATE  ; 

-[  SC*  BRACE  [ NEGFLG  1SET  IMMEDIATE  ; 

] LIT  SKI F , HERE  DUP  0 , CRM ASK  HERE  NVRD  MOVE  NWRD  2*  DF  +! 

HERE  SWAP  ! 2+  LIT  LIT  , , NEGFLG  $ 

IF  NEGFLG  OSET  LIT  NEGCAT  ELSE  LIT  TSTCAT  THEN  , NCOND  1+!  IMMEDIATE  ; 

: CEOS]  LIT  ENDSNT  , NCOND  1+!  IMMEDIATE  ; 

] . SC  TSTWRD 

: ->  NCOND  S 0<  IF  LIT  ADVLEX  , THEN  ARCTYPE  S 5 = I F LIT  SETSTAR  , THEN 
STATFND  LIT  SKPS  , ' ; , IMMEDIATE  ; 

: ,,  ARCTYPE  0 6 = IF  LIT  POPND  , ELSE  ARCTYFE  0 7 = IF  LIT  JMPND  , 

THEN  THEN  HERE  SWAP  ! IMMEDIATE  ; 

: TO  STATFND  LIT  1T0EX  , LIT  LIT  , HERE  , LIT  2T0EX  , IMMEDIATE  ; 

SC. I ACTDF 


].SC  ATNDF 


: PARSE  SC*  ATNDF  PARSE  ; 


( ■«■■■■■»•*■■»■*»■■«*•*■■«*■  Text  Input  ===  = = ) 

0 VARIABLE  TXTP 

: TEXSTRT  ELEX  3 1«-  DYNBAS  ! TXTP  1SET  SENTP  1SET  ; 

: TEXFIN  [ . ] SEN'TP  8 SWAP  \ADMOVE  SENTP  8 2 \D+  DUP  1+  -2  AND  DUP  SENTP  I 
NXTAVL  ! TXTP  8 - TXTP  3 -1  \D+  \D1  ; 

: CHKPUNC  DUP  44  = IF  DROP  1 ELSE  4b  = IF  2 ELSE  0 THEN  THEN  ; 

: CHKWRD  BEGIN  HERE  \8  0-  WHILE  RDLN  OILN  ! OIAD  ! WORD  ENDWH1LE 
HERE  DUP  1+  SWAP  \§  SENTP  3 SWAP  \ADMOVE  SENTP  8 HERE  \0  \D+  DUP 

SENTP  ! -1  \D*  DUP  \D8  CHKPUNC  DUP 

IF  SWAP  SENTP  ! 1 IF  1 ELSE  0 THEN  ELSE  SWAP  DROP  THEN 
32  SENTP  6 \D!  * SENTP  I ; 

: GETTXT  TEXSTRT  BEGIN  WORD  CHKWRD  END  TEXFIN  ; 


( = = = » = = = = = = Morphology  Processing- Words  ■«»*•■«■••»■«««»»»■»■■*»»■) 

0 VARIABLE  FSAARC  0 VARIABLE  FSAPT  0 VARIABLE  LEXWRK 

: DEFMATCH  VARIABLE  ; : LEXWRK  3 FSAPT  I l SC.  V PATDEF  ] 01NT 
8 FNDSTATE  SKPS  ; 

0 DEFMATCH  1 MATCH 

: MATCH  NEWFRAME  1 MATCH  [ SC.  I PATDEF  J 01  N'T  OLDFRAME  ; 

: ARC ENT 2 FSAARC  3 8 FSAARC  ! ; 

: TSTCHAR  FSAPT  8 \D8  SWAP  \8+  DUP  ROT  ♦ SWAP 
DO  DUP  I \$  = IF  DROP  0 TERM  THEN  LOOP  0=  ; 

: TSTFAIL  IF  FSAPT  !♦!  ELSE  FSAARC  8 2+  GOTO  THEN  ; 


( Morphology  Compiler  Words  ••••■*••■*■*•««»•••*•»**■»*) 

: PATTERN  WORD  HERE  ' 1 MATCH  ! 6 DP  +! 

( SC.  t PATDEF  SC. V FSADEF  SC. V FEATURES  ] OINT  ; 

: ENDPATTERN  [ >.  SC  PATDEF  SC.  I FSADEF  SC. I FEATURES  ] OINT  ; 

SC.  [ FSADEF 

: : S 2 STATE  ! CODE  IMMEDIATE  DUP  FSAARC  ! 2+  GOTO  ; 

: 0 , LIT  0 , ' ; , STATE  OSET  IMMEDIATE  ; 

BASE  8 OCTAL 

t TSTCMPIL  LIT  SKIP  , HERE  0 , WORD  HERE  \8 

7 = IF  HERE  1+  [ * BLANK*]  \COMF  0-  IF  20001  DP  C ! THEN  THEN 

HERE  \3  2+  -2  AND  DP  +!  HERE  OVER  ! 2 + LIT  LIT  , , LIT  TSTCHAR  , ; 
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BASH  ! 

: ARCENTFSA  HERE  0 , LIT  ARCFNT2  , TSTCMF1L  ; 

: JA  ARCTYPE  OSET  ARCENTFSA  IMMEDIATE  ; 

: : F ARCTYPE  1SET  ARCENTFSA  IMMEDIATE  ; 

: =>  LIT  TSTFAIL  , STATFND  LIT  SKPS  , ' ; , IMMEDIATE  ; 

: t LIT  TSTFAIL  , SC*  BRACE  [ IMMEDIATE  ; 

: ] LIT  SKIP  , HERE  0 , CRMASK  HERE  NWRD  MOVE  NWRD  2*  DP  +! 

HERE  OVER  ! 2*  LIT  LIT  , , ' ; , IMMEDIATE  ; 

: ,,  HERE  SWAP  ! IMMEDIATE  ; 

]. SC  FSADEF 


NWRD  S ♦ CONSTANT  LEXLEN  ( LENGTH  OF  LEXICAL  ENTRY) 

0 VARIABLE  STRLEN  0 VAR  I API r PVLEX  0 VARIABLE  ALTLEX 
0 VARIABLE  LEXB 

: LEXENTCK  \g  + SWAP 

IF  \g  + LEXWRK  t DTOA  ROT  OVER  OVER  + \g  DUP  32  = SWAP  45  = OR  DUF 
IF  DROP  \COMP  0=  ELSE  SAVE  2 DROP  DROP  UNSAVE  THEN 
ELSE  DROP  1 THEN  ; 

: MAX  ILEX  0 PVLEX  g 0 STRLEN  g LEXWRK  g LEXLEN  GTNEW  DUP  SAVE 

D!  ♦ D!  + D!  *•  D!  + D!  + NWRD  ADMOVE  UNSAVE  DUP  PWORD  ; 

: PVLINK  OVER  OVER  SWAP  3 D*  D! 

BEGIN  DUF  WHILE  OVER  SWAP  2 D+  D!  + ID*  Dg  ENDWH1LE  2DROP  ; 

: ALTLINK  4 D*  D!  ; 

: MAKLEXUNT  1*  \g  + OVER  STRLEN  ! ♦ 1+  -2  AND 

g+  DUP  MAK ILEX  SWAP  OVER  DUP  ALTLEX  ! PVLEX  g PVLINK  ROT 

1-  DUP  IF  0 DO  NWRD  2*  * DUP  MAK ILEX  DUP  ALTLEX  g!  ALTLINK  LOOP  DROP 

ELSE  2 DROP  THEN  PVLEX  I STRLEN  g 1 + LEXWRK  *!  ; 

: MAKMATCHUNT  FSAPT  g DUP  LEXWRK  g - 1-  STRLEN  ! 

SWAP  MAK 1 LEX  DUP  PVLEX  g!  PVLINK  LEXWRK  ! ; 

: NEXTLEXENT  DUP  \g  ♦ DUP  \g  255  = 

IF  DROP  LEXB  g 1+  DUP  LEXB  ! BLOCK  THEN  ; 

: LX LOOKUP  SLEX  DUP  LEXB  ! BLOCK 

BEGIN  DUF  LEXENTCK  0-  WHILE  NEXTLEXENT  ENDWH1LE 
DUP  \g  IF  MAKLEXUNT  1 ELSE  DROP  0 THEN  ; 

: MATCHLOOKUP  MATCH  DUP  IF  MAKMATCHUNT  1 THEN  ; 

: BOMB  CR  LEXWRK  g GTAD  10  TYPE  ABORT!  ; 


: LOOKUP  LXLOOKUP 
IF  1 

ELSE  MATCHLOOKUP 
IF  1 

ELSE  LEXWRK  2 GTAD  [ . ] \COMP  DUP 

IF  [ UNRECOGNIZABLE  STRING!]  TYPE  BOMB  THEN- 
THEN 
THEN  ; 

: SENSTRT  TXTP  g LEXWRK  ! SENTP  g FVLEX  ! 

0 0 0 0 S GTNF.W  D!  - D!  * UUP  3 IK  SWAP  D!  + D!  ♦ D!  + SENTP  ! ; 

: SENFIN  STRLEN  OSET  LEXWRK  OSET  SC*  BRACE  ( CRMASK  MAM LEX  DUP 
PVLEX  g PVLINK  DUP  2 D + D!  NXTAVL  g FRAMSTART  ! ; 

: MAKESENT  SENSTRT  BEGIN  LOOKUP  WHILE  ENDWHILE  SENFIN  ; 


( »»*»><»«»»  = = = = = = M Utility  Words  ====================== 

: >.SC  ] . SC  ; ( THIS  TO  FAKE  "I",  WHICH  LOOKS  FOR  "] ") 

: DDUMP  GTAD  SWAP  GTAD  SWAP  DUMP  ; 

: \ DDUMP  GTAD  SWAP  GTAD  SWAP  NDUMP  ; 

0 DEFPARSE  SUBPARS 

: SUBPARSE  WORD  HERE  ’ SUBPARS  ! 6 DP  - ! SUBPARS  6 DP  ! ; 

; FRMDMP  FRAMBASE  g DUP  CUROF  8 * DDUMP  ; 

: >>  GETTXT  MAKESENT  PARSE  ; 

: >>>  GETTXT  MAKESENT  SUBPARSE  ; 

3.0  ERL  Machine 

( b======s3======s==========  erl  Pseudo-Machine  ================== 

( Miscellany) 

: DP!  DP  ! ; 

0 VARIABLE  ETRACE 

CODE  SKPS  IC  R )+  MOV,  V S )♦  MOV,  V g> + JMP, 

CODE  SKPTO  R ) + TST,  ' SKPS  P JMP, 

: t.  STATE  DSET  IMMEDIATE  ; ( LEAVE  COMPILE  MODE  IN  DEF. ) 

: .]  2 STATE  ! ; ( REENTER  COMPILE  MODE  IN  DEF.  > 

: f:  2 STATE  ! ; ( ENTER  COMPILE  MODE  TO  STORE  CODE> 

: :]  STATE  OSET  IMMEDIATE  ; ( LEAVE  COMPILE  MODE) 

8 C 8 12  C 12  16  C 16  18  C 18  20  C 20  22  C 22  24  C 24 

( Special  Registers) 


0 VARIABLE  V 


0 VARIABLE  VI 


0 VARIABLE  YY 


0 VARIABLE  YY1 


p 


1 


j 


[ 

1 


0 VARIABLE  X 0 VARIABLE  XI  0 VARIABLE  TR  0 VARIABLE  A 

0 VARIABLE  B 0 VARIABLE  Y 0 VARIABLE  V 


( P_TERM  t'lk-s  a point*  r to  a i tlue  cell,  prints  the  contents) 
RECURS  P_TERM 

: P.ATOM  I D+  1 DUP  FRAMSTART  I.  IF  D8+  SWAP  GTAD  S'. 

ELSE  2+  COUNT  TYP1  THEN  ; 

: P_  I NT  1 D+  ['■  CONVERT  COUNT  TYP1  ; 

: P.GVAR  [ G . I : I 10NVER1  COUNT  TYP1  ; 

: P.LVAR  [ LJ  7YP1  CONVERT  COUNT  TYP1  ; 

: P_VOI  D UkO:’  [ < VO  I D - ] TYPI  ; 

: P_SKEL  Y 8 SWAP  D8  Y ! 

S+  SWAP  * COUNT  TYF 1 SWAP  2+  ? SWAP  [ (]  ROT 
0 DO  TYPI  3 + 6-  ROT  ROT  EXEC  P.TERM  l ,]  LOOP 
2DROP  DROP  )]  TYPI  Y ! ; 

I ARRAY  P.TYPF  ' P.GVAR  . ’ P_LVAR  , ' P.VOID  , ' F_ATOM  , 

’ P_I  NT  , ' P_.SK  EL  , 

:R  P.TERM  NXTAVL  S'  AF  1 JP  D DUP  S L>  IF  DROP  10  THEN 
P.TYPE  + A EXEC  NXTAVL  ! ; 

0 VARIABLE  P.SW 

: P.TERM  P_SW  8 IF  CR  P.TERM  ELSE  DROP  THEN  ; 


( Functor  Literals) 

: FNLIT  CONSTANT  96  DELIM  ! WORD  HERE  N£+  + 5 + -2  AND  DP!  ; 
0 FNLIT  NIL  nil 
2 FNLIT  CONS  cons 


< Field  Definitions  in  Local  Stack' 

: FIELD  CONSTANT  $ V 8 + ; 

0 FIELD  AF  2 FIELD  XF  4 FIELD  V1F  6 FIELD  TRF 

8 FIELD  FLF  10  FIELD  YVF  12  FIELD  DPF  14  FIELD  N'XF 


( Trail  Management  Words) 

: TRPUSH  TR  } -1  D+  DUP  TR  ! D!  ; 

: LTRAIL  DUP  Y L < IF  TRPUSH  ELSE  DROP  THEN  ; 

t GTRA1L  DUP  VI  L<  IF  W TRPUSH  ELSE  DROP  THEN  ; 

: EDTRAIL  VY  3 TRF  S TR  S OVER  OVER  - 

IF  DO  I D8  OVER  OVER  L'  IF  DROP  ELSE  DOSET  THEN  2 +LOOF 
ELSE  2DSOP  THr\  DROP  ; 

: UNTRAIL  TRF  3 TR  OVER  OVER  - 
IF  DO  1 Ds  DUF  IF 


L 

h 

H 
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DUP  1 AND  IF  0 0 ROT  1-  D!  + D!  ELSE  DUP  0 0 0 ROT  D!  + D!  OSET  THEN 
ELSE  DROP  THEN  2 +LOOP 
ELSE  2 DROP  THEM  TRF  @ TR  ! ; 


( New  Global  Stack  Management  Words) 

: \GTNEW  NXTAVL  0 DUP  ROT  + DUP  NXTAVL  ! 

TR  0 L>  = IF  [ GLOBAL  STACK  OVERFLOW!]  TYPE  ABORT!  THEN  ; 
: GTNEW  2*  \GTNEW  ; 


( Clause  and  Procedure  Control  Instructions) 

: GOS  GOTO  ; 

: ENTER  VV  8 VVF  ! X 0 XF  ! A 0 AF  ! VI  0 V1F  ! TR  0 TRF  ! 

HERE  DPF  ! NXTAVL  0 NXF  ! V 0 VV  ! VI  0 VV1  ! ; 

: HEAD  V 0 + DP!  VI  0 + DUP  NXTAVL  0 - DUP  0>  IF  \ GTNEW  DROP  NXTAVL  ! 

ELSE  2 DROP  THEN  A 0 B ! XI  0 Y ! VI  0 W ! ; 

: NECK  V 0 X ! VI  0 XI  ! HERE  V ! NXTAVL  0 VI  ! ; 

: FOOT  VV  @ X 0 L<  IF  X 0 DUP  V ! DP!  THEN  V 0 X 0 V ! 

AF  0 A ! XF  0 DUP  X ! V ! V1F  0 XI  ! V ! A 0 + GOTO  ; 

: NECKFOOT  NXTAVL  0 VI  ! VV  0 V 0 = IF  HERE  V ! ELSE  V 0 DP!  THEN  A 0 + GOTO 

: CUT  X 0 DUP  V ! VVF  0 DUP  V ! VV  ! V1F  0 VV1  ! EDTRAIL  + DUP  V ! DP  ! ; 

: NECKCUT  V 0 X ! VI  8 XI  ! V +!  V 0 DP  ! VI  +! 

V 0 X 0 V I VVF  8 DUP  V ! VV  ! V1F  0 VV1  ! V I EDTRAIL  ; 

: NECKCUTFOOT  NXTAVL  0 VI  ! V 0 VV  0 = 

IF  V 0 VVF  0 DUP  VV  ! V ! V1F  0 VV1  ! V ! EDTRAIL  THEN  A 0 + GOTO  ; 

: RETURN  HERE  8 - DUP  DP  ! 0+  0+  0+  0 VI  ! Y ! B ! GOTO  ; 

: FEHL  VV  0 V ! V1F  0 VI  ! AF  0 A ! XF  0 DUP  X ! ' V1F  0 + 0 XI  ! DPF  0 DP  ! 

NXF  0 TRUNC  UNTRAIL  ; 

: FAIL  VV  0 V 0 <>  IF  FEHL  ELSE  UNTRAIL  THEN  UNSAVE  DROP  FLF  0 GOTO  ; 

: FEHL  FEHL  UNSAVE  DROP  FLF  0 GOTO  ; 

: CALL  UNSAVE  DUP  SAVE  A ! SKPTO  ; 

0 VARIABLE  PTRY 

: TRY  PTRY  0 IF  CR  [ TRY]  TYPE  DUP  PRSTNM  THEN  UNSAVE  DUP  SAVE  FLF  ! GOTO  ; 

: BACK VV  V 0 VVF  0 DUP  VV  ! V ! V1F  @ VV1  ! V ! ; 

: TRYLAST  PTRY  0 I F CR  [ TRYLAST]  TYPE  DUP  PRSTNM  THEN  BACKVV  GOTO  ; 
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C Derefererv  iu&  Words) 


RECURS  GDEREF 

: R GDEREF  DUP  n«  0 IE  DUP  1 0+  D(*  DUP  0-  IF  DROP 
ELSE  SWAP  DROP  GDEREF  THEN  THEN’  ; 

: LDEREF  DUP  ’■  0 IF  DUP  2 GTNEW  DUP  ROT  2 ROT  PI  + D!  DUP  ROT  DDF  LTRAIL  ! 
ELSE  3 GDEREF  THEN  ; 


( Access  Words) 

VARACCESS  Y 0 ♦ GDEREF  ; 

GLOBAL ACCESS  XI  ♦ GDEREF  ; 

LOCALACCESS  X 8 + LDEREF  ; 

VOIDACCESS  DROP  NXTAYL  8 4 OVER  D!  ; 

ATOMACCESS  2 GT.NEW  DUP  ROT  o ROT  D!  + D!  ; 
INTACCESS  2 GTNEW  DUP  ROT  A ROT  D!  * D!  ; 
MOLACCESS  2 GTNEW  DUP  ROT  Y SWAP  ROT  D!  * D!  ; 


( Match  Code  Instructions) 

: SELECTOR  CODE  SWAP  B 8 ♦ 8 + 0 EXEC  DUP  P_TERM 
DUP  D0  DUP  B b IF  DROP  10  THEN  ROT  + 8 GOS  ; 

: VUSKEL  DUP  GTRAIL  D!  + W 0 SWAP  D!  ; 

: DFAIL  2 DROP  FAIL  ; 

: CKFUNC  DUP  10  L>  IF  3 ELSE  2 DROP  UNSAVE  DROP  FAIL  THEN  SWAP 
DUP  10  L>  IE  0 ELSE  2 DROP  UNSAFE  DROP  FAIL  THEN  = IF 
ELSE  UNSAFE  DROP  FAIL  THEN  ; 

: SKUSKEL  OVER  OVER  D0  CKFUNC  UNSAVF.  DUP  SAVE  , B 8 , Y 8 , W 8 , 

D0  + 00  Y ! 4 + @ B ! 2+0  GOTO  ; 

SELECTOR  USKEL  ’ VUSKEL  PUP  , , ' DROP  , ' DFAIL  , ' DFAIL  , 

' SKUSKEL  , 

: ASLVAR  SWAP  V 8 + ! ; 

: LVLVAR  DUP  0 0 ROT  D!  + D!  ASLVAR  ; 

SELECTOR  III. VAR  ' ASLVAR  , ' l.VLVAR  , ' DROP  , ' ASLVAR  DUP  DUP  , , , 

: LVG'  SWAP  W 3 ♦ DUP  ROT  1 D+  D8  ! 0 0 ROT  D!  + P!  4 NXTAVL  -!  ; 

: GVG\  uv  0 ROT  W 0 . D!  ♦ D!  ; 

: ASGVAR  SWAP  W 0 + DUP  GTRAIL  2 DDMOVE  ; 

SELECTOR  UGVAR  ’ GVGVAR  , * LVG VAR  , ' DROP  , ' ASGVAR  DUP  DUP  , , , 

: LVATOM  6 SWAP  D!  + D!  ; 

: GVATOM  DUP  GTRAIL  LVATOM  ; 

: EQATOM  1 D+  D8  < > 1 F FAIL  THEN  ; 

SELECTOR  UATOM  ' GVATOM  , ' LVATOM  , ' DROP  , ’ EQATOM  , ' DFAIL  DUP  , , 
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: LVINT 

8 SWAP  D!  + D!  ; 

: GVINT 

DUP  GTRAIL  LVINT  ; 

: EQ1NT 

1 D+  D0  0 IF  FAIL 

THEN  ; 

SELECTOR 

UINT  ' GVINT  , ' 

LVINT  , 

' DROP  , 

' DFAIL  , ’ FQINT  , 

' FAIL 

: GVUREF  W 0 - SWAP  LIT  UGVAR  SKPS  ; 

: ATUREF  1 D+  D@  SWAP  LIT  UATOM  SKPS  ; 

: INUREF  1 D+  D0  SWAP  LIT  UINT  SKPS  ; 

: OSKUREF  DUP  GTRAIL  D!  + D!  ; 

: 2SKUREF  D!  ♦ D!  ; : 4SKUREF  2DROP  DROP  ; : SFAIL  DROP  2DROP  FAIL  ; 

: 10SKUREF  OVER  OVER  D@  CKFUNC  UNSAVE  DUP  SAVE  , B 0 , Y 0 , W 0 , 

D0+  D@  Y ! 4 4 ® B ! SWAP  W ! 2 + t GOTO  ; 

SELECTOR  SSKUREF  ' OSKUREF  , ' 2SKUREF  , ' 4SKUREF  , ' SFAIL  DUP  , , 

' 10SKUREF  , 

: SKUREF  D0  + D®  SWAP  ROT  LIT  SSKUREF  SKPS  ; 

I ARRAY  REFTYPE  ' GVUREF  ,0,0,  ' ATUREF  , 

' INUREF  , ' SKUREF  , 

: ULREF  SWAP  V ® + LDEREF  DUP  D0  DUP  8 L>  IF  DROP  10  THEN  REFTYPE  + 0 GOS 

: UGREF  SWAP  W 0 + GDEREF  DUP  D®  DUP  8 L>  IF  DROP  10  THEN  REFTYPE  + 0 GOS 

: IN  IT  W 0 DUP  SAVE  + SWAP  UNSAVE  + SWAP  DO  I DOSET  2 +LOOF  ; 

: LOCALIN1T  V 0 DUP  SAVE  + SWAP  UNSAVE  + SWAP  DO  I OSET  2 +LOOP  ; 


( Primitive  predicates  of  ERL) 

: FFAIL  FAIL  ; 

: FEAT  ENTER  BACKVV  0 16  HEAD  B 0 0+  0 EXEC  D0+  D@  SWAP 

6 <>  IF  DROP  FFAIL  THEN  DUP  FRAMSTART  ® L>  IF  DROP  FFAIL  THEN 
DUP  SENTP  ® L<  IF  DROP  FFAIL  THEN 

R 0 4 + 0+  0 EXEC  D0+  D@  SWAP  6 o IF  DROP  FFAIL  THEN 

2+  [ SC.V  FEATURES  3 OINT  ?FIND  [ SC. I FEATURES  3 OINT 

DUP  0=  IF  DROP  FFAIL  THEN  2+  TSTCAT  IF  8 NECKFOOT  ELSE  FFAIL  THEN  ; 

: TYPATOM  ENTER  BACKVV  0 16  HEAD  B 0 0+  0 EXEC  D0+  D0  SWAP 
6 <>  IF  DROP  FFAIL  THEN 
DUP  FRAMSTART  0 L>  IF  2+  COUNT  TYPE  ELSE 
D0+  SW!AP  GTAD  SWAP  D0  TYPE  THEN  4 NECKFOOT  ; 

: TYPLEX  ENTER  BACKVV  0 16  HEAD  B 0 0+  0 EXEC  D0*  D0  SWAP 
6 <>  IF  DROP  FFAIL  THEN 
DUP  FRAMSTART  0 L>  IF  DROP  FFAIL  ELSE 
D0+  SWAP  GTAD  SWAP  D0  TYPE  THEN  4 NECKFOOT  ; 

: TYPCR  ENTER  BACKVV  0 16  HEAD  CR  4 NECKFOOT  ; 

: LEXEQ  ENTER  BACKVV  0 16  HEAD  B 0 0+  0 EXEC  D0  + D0  SWAP 

6 <>  IF  DROP  FFAIL  THEN  DUP  FRAMSTART  0 L'  I F DROP  FFAIL  THEN 
DUP  SENTP  0 L<  IF  DROP  FFAIL  THEN 
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B C J * J EXEC  D3*  D ? SWAP  6 <>  IF  DROP  FFA1L  THEN’ 
2*  CMPVRD  IP  8 f ECKFOOl  EL 5E  FFAIL  THEN  ; 


4.0  ERL  Compiler  - Pass  1 


* EVENT  REPRESENTATION  LANGUAGE  COMPILER  * 

* PASS  1 OUTPUT  VARIABLE  INFO  AND  INSTRUCTION,  DATA  SEQUENCE  • 


************************  DATA  DEFINITION'S  ************************************ 


DATA (' LINK (NEXT, VALUE) ');  DATA (' VAR_REC (NOCC,  TYPE,  OFFSET) ') 

* 

*************************  INITIALIZATIONS  ************************************ 
* 

INPUT (.  IN'STR,  1,  'SY:  TEMPLATE.  ERL') 

OUTPUT  (.  Oi'TSTR,  . , ' SY:  TEMPLATE.  I NT') 

OUTPUT  (.  CONSOL,  7) 

5 ANCHOR  1 

LINC  = 2;  GINC  4 

SETEX IT  ( ' ERR' ) ; SERRLIMIT  1;  (jSTLIMIT  = -1 

* 

***********************  FUNCTION  DEFINITIONS  ********************************* 

* DEFINES 

DEFINE  COPT  i PATTERN)  '); 

DEFINE  CSlNAMK)  ’):  DEFINE  ('  S_  (NAME)Tl,  TO,  T3,T4’) 

DEFINE  CPU., H(X)  ');  DEFINE  C POP  ()  ');  DEFINE  ('TOP  ()  ') 

DEFINECOSPAN(FAT)  '); 

: (ENDEF) 

* 

* DEFINITIONS 

ERR  DUMP  12)  : (ABORT) 

OS  PAN 

OSPAN  SPAN  (P  AT)  I NULL  : (RETURN) 

PUSH 

PUSH.  POP  LI NK  (PUSH  POP,X);  PUSH  - . VALUE  (PUSH. POP)  : (NRETURN) 

POP 

1 DENT  (PUSH. POP)  : S (FRETURN) 

POP  VALUE  (PUSILPOP);  PUSH  POP  --  NEXT  (PUSH  POP)  : (RETURN) 

TOP 

TOP  = DIFFER  (Pt!SH_POP)  . VALUE  (PUSH_POP)  :F (FRETURN)  S (NRETURN) 

OPT 

OPT  PATTERN  I NULL  : (RETURN) 
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************************  SEMANTIC  ROUTINES  ****** 

* MAIN  ROUTINE  DEFINITIONS 
S 

S = EVAL  ("NULL  . *S_(.  " NAME  ")")  : (RETURN) 

S_  S_  = .DUMMY;  CMDOUT  = NAME  :($('P1_'  NAME)) 

* SEMANTIC  ROUTINES 

* 

P1_VAR 

T1  = POPO;  CMDOUT  = T1 

VAROUT  = T1  ' (LECNEST,  1)  ",'G’) 

: (NRETURN) 

P1_VDVAR  : (NRETURN) 

Pl_ATOM  CMDOUT  = POP  ()  : (NRETURN) 

P1_INT  CMDOUT  = POPO  : (NRETURN) 

Pl.CONSI  : (NRETURN) 

Pl.INCL  : (NRETURN) 

P1_NIL  : (NRETURN) 

P1_LISTI 

NEST  = NEST  + 1 
: (NRETURN) 

Pl.LISTF 

NEST  = NEST  - 1 
: (NRETURN) 

P1_INC  : (NRETURN) 

Pl.SKELI 

NEST  = NEST  ♦ 1;  CMDOUT  = POPO 
: (NRETURN) 

P1_SKELF 

NEST  * NEST  - 1 
: (NRETURN) 

Pl_GOAL  : (NRETURN) 

P1_CNEK  : (NRETURN) 

Pl.CFOOT  : (NRETURN) 
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PI  CM'  : (NRFTURN) 


P 1_CNC E : (NRFTUKN) 


PI  .CNF  : (NRETUKN) 
P1_E0CL  : (NRETURN) 


PI  (Nil 

PUSH  POP  ; NEST  0 
: (NRETURN' 

END  EE 


**««******<»»*  i \ Ei'K  ,:i' I.  MAIN  SYMBOL  "CLAUSE"  ********************* 


* 


I 1 ' . CHA  • 


SOLO_CHAK 

(» ALPHA!' M TAB (AM  1.EN  (9t  UNQALPHA 
UNQALPHA  ARB  "" 

UNQALPHA  ARB 

DIGITS  •-  ’0lP.S4St)789' 


LCLETTERS 
UC LETTERS 
ALPHANUMER I OS 
NUMBER 
SYMBOL 
WORD 

QUOTED. NAME 


' diicMeighi  : Wlmnopq  rst  uvw xyz ' 

' AfcCDFFGHI J KLMNOPQRSTUVWXYZ  ’ 
UCLETTERS  LCLETTERS  DIGITS 
ANY  (.DIGITS')  OS  PAN  (DIGITS) 

HAR)  OSP AN (SYMBOL  CHAR) 
ANY  (L  LE  I' TER  ' OSPAN  (Al.PHANUMER  1 CS) 
SPAN (UNQALPHA  "" ) . *PUSHO 
I SPAN (UNQALPHA  ) . *FUSH() 


FULL  STOP 
VARIABLE 

INTEGER 

ATOM 


■* 

4 

4 

LISTEN  i'R 

4 

4 


LIST 

4 

4 

4 

ARGU'D  A IN 


# t 

(ANY  w ’LETTERS)  OSFAN ( ALPHANUMERICS) ) . *PUSH()  S(.  VAR) 
I *_•  S(.VDVAR) 

(NUMBER  I ’ ' NUMBER)  . «PUSHO  S(.  I NT) 

QUOTED  NAME 
I ( WORD 
I SYMBOL 
! SOLO_CHAR 
) . *EUSHO 

•TERM  ARBNO  ( ’ , * S (.  INCL)  *TERM) 

( S(.  CONS  I ) *TERM 

I NULL  S(.  CONS  I ) S(.  NIL) 

) 

’ I]  ’ S(.  NIL) 

I ’ [ ’ S (.  LIST!) 

LISTEXPR 
* J * S(.  LISTF) 

•TERM  ARBNO  S (.  INC)  *TERM) 


A-  IB 


TERM 

= ATOM 

4 

( ' ('  S (.  SKELI)  ARGUMENTS  ')  ' S (.  SKELF) 

4 

1 NULL  S(.  ATOM) 

♦ 

) 

4 

t VARIABLE 

4 

1 INTEGER 

4 

1 LIST 

GOAL 

= (TERM  I '!  ' . aPUSHO  S (.  ATOM) ) S (.  GOAL) 

GOALS 

= GOAL  ARBNO  (' , ' GOAL) 

4 

OPT  (',  ' aGOALS) 

HEAD 

= TERM 

CLAUSE 

= S(.  INI)  HEAD 

♦ 

( S(.  CNEK)  GOALS  S (.  CFOOT) 

1 * A • f 

4 

4 

1 A “I 

( ' , ’ S (.  CNC)  GOALS  S (.  CFOOT) 

4* 

1 NULL  S(.  CNCF) 

4 

) 

4 

1 NULL  S(.  CNF) 

4 

) FULL^STOP  S(.  EOCL) 

AAAAAAAAAA**AA*****************A***AftA****A*********A***«************»  *** 

* MAIN  PROGRAM 


aa  READ  AND  COMPILE  A CLAUSE 

CMPL 
STMT  = 

* READ  A LINE  AND  ADD  IT  TO  STRING  "STMT" 

RDLP 

TRIM (INSTR)  OSPANC  ')  ARB  . LINE  ' I NULL)  . FSRPOS(O)  :F(EOIN) 

* UNLESS  IT'S  A COMMENT  LINE 

LINE  ANY  ('I/*’)  : S (RDLP) 

a SQUEEZE  OUT  BLANKS 
5ANCHOR  «=  0 

SQZ  LINE  ' ' = : S (SQZ) 

5ANCHOR  = 1 

STMT  = STMT  LINE  FS 

IDENT(FS)  : S (RDLP) 

a A PERIOD  AT  THE  END  OF  LINE  TERMINATES  A CLAUSE 
STMT  * STMT  ' ' 

a PUT  THE  SOURCE  IN  THE  OBJECT  AS  A COMMENT 
OUTSTR  = '(  ' REPLACE  (STMT,  ' ()  »,’{> ')  ')  ' 

a PARSE  AND  OUTPUT  THE  VARIABLE  INFO  FOLLOWED  BY  A NULL  LINE 
OUTPUT  (.  VAROUT,  2) 

STMT  CLAUSE  : F (ERROR) 

VAROUT  = 

DETACH  (.  VAROUT) 

a PARSE  AND  OUTPUT  THE  COMMAND  AND  DATA  STUFF 
OUTPUT  (.  CMDOUT,  2) 

STMT  CLAUSE  :F  (ERROR) 

DETACH (. CMDOUT)  : (CMPL) 
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* END  OF  INPUT 
EOIN 
: (END) 

ERROR 

CONSOL  = STMT 

OUTSTR  = *******  SYNTAX  ERROR  IN  ABOVE  CLAUSE  **********' 
CONSOL  - OUTSTR 
: (CMPL) 

END 

6.0  ERL  Compiler  - Pass  2 


EVENT  REPRESENTATION  LANGUAGE  COMPILER 
PASS  2 - RFAD  INTERMEDIATE  STUFF,  PRODUCE  FORTH  OUTPUT 


************************  DATA  DEFINITIONS  ********************************* 

* 

DATA (’LINK (NEXT, VALUE) ');  DATA  (' VAR_REC (NOCC,  TYPE,  OFFSET) ’) 

DATA  ('  FORTH  (MATCH,  GOAL,  OFF)  j 

* 

*************************  INITIALIZATIONS  *********************************1 

• 

b = ' t = ; c = ' , ^ALPHABET  TAB(127)  LEN(l)  . sp 

IDT  = TABLE  (70) 

I DT  < * feat  2’>  = 'FEAT';  IDT<’cons  2'>  = 'CONS';  IDT<'nil  0'>  = 'NIL'; 

I DT< ' typatom  l'>  = 'TYPATOM';  IDT<'typlex  1 ' > = 'TYPLEX'; 

IDT< 'typer  1 ' > - ' TYPCR ' ; IDT<'fail  0’>  = ' FEHL' ; 

I DT < ' ! 0'>  = 'CUT';  IDTc's  5*>  = 'S';  IDT<’np  4'>  = 'NP' 

I DT < ' q p 2 ' > = ' QP ' ; IDT.'nnode  2’>  = ' NNODE ' ; IDTv'pp  3'>  = 'PP' 

I DT < ' p l'>  = ' P ' ; I DT < ' vg  4'>  = 'VG';  IDT<'v  2*>  = 'V' 

I DT  < 'date  3 ' > = 'DATE';  IDT<.'Iexeq  2'>  = ' LEXEQ' 

I DT< 'dp  3 ' > = 'DP' 

PREDT  = TABLE  (50);  PREDN  --  TABLE  (50) 

PREDN< ' FEAT' > = 'FEAT';  PREDN< ' CONS ' > = 'CONS';  PREDN<'NIL’>  = 'NIL'; 
PREDN< 'TYPATOM' > = 'TYPATOM';  PREDN< ' TYPLEX ' > = 'TYPLEX'; 

PREDN< 'TYPCR' > = 'TYPCR';  PREDN< ' FEHL' > = 'FEHL';  PREDN<’CUT'>  = 'CUT'; 
PREDNv ' S ' > = 'S';  PREDN ' NP ' > - 'NP';  PREDN<'QP'>  - 'QP'; 

PR EDN< 'NNODE' > = 'NNODE';  PREDN<’PP'>  = 'PP';  PREDN<’P’>  * ’ P ' ; 

PREDN< ' VG ' > = 'VG';  PREDN<'V'>  = 'V';  PREDN< ' DATE' > = 'DATE'; 

PREDN< ' LEXEQ ' > 'LEXEQ' 

PREDN< ' DP ' > = 'DP' 

INPUT (.  INSTR,  1,  'SY:  TEMPLATE.  INT') 

OUTPUT  (.  OUTSTR,  2,  'SY:  TEMPLATE.  4TH' ) 

OUTPUT  (.  CONSOL,  7) 

^ANCHOR  = 1 

PID  * 0;  AID  = 0;  FID  = 0;  CID  = 0 
PREDLST  = 

L1NC  = 2;  G1NC  = 4 


SETEXIT  ('ERR');  5ERRLIMIT  = 1;  IjSTLIMIT  = -1 

* 

***********************  FUNCTION  DEFINITIONS  ****************************** 

* DEFINES 

DEFINE (’EMITPR(PRED)  ');  DEFINE  (’NEW(I)  ’);  DEFINE!'  S_  (NAME)  Tl,  T 2,  T3,  T4') 
DEFINE (' PUSH  (X) ’);  DEFINE!' POP  0 ' ) ; DEFINE  ('TOP  0 ' ) 

DEFINE (' TI D (LET,  NAME, ARITY) '); 

DEFINE  ('EMIT (LINE) L');  DEFINE  (' DEC  (I) '); 

DEFINE (' FIN_HEAD  0 ') 

: (ENDEF) 

* 

* DEFINITIONS 

ERR  DUMP (2)  : (ABORT) 

FIN_HEAD 

Tl  = MATCH  (POP  () ) ; ARGNO  = POP();  T3  = TI  D ( ' F\ POP  () , ARGNO) ; 

T4  = 'C'  NEW (.  CID) ; CLOUT  = CLOUT  T4  b b; 

PREDT<T3>  = PREDT<T3>  t T4  " TRY” 

PUSHO  * Tl;  Tl  = 16  + 2 * (NVAR  - NGLOB) ; T2  = 4 * NGLOB 

CLOUT  = CLOUT  T2  b Tl  " HEAD  " POP!) 

CLOUT  = GT  (Tl  - LOFF, 0)  CLOUT  Tl  b LOFF  " LOCALINIT  " 

CLOUT  = GT (T2  - GOFF, 0)  CLOUT  T2  b GOFF  " INIT  " 

: (RETURN) 

EMIT 

OUTSTR  = LT  (SIZE (LINE), 81)  LINE  :S (RETURN) 

L = 80 
EMIT_1 

LINE  TAB  (*L)  $ DEC  (.  L)  . OUTSTR  ('  ' | RPOS(O))  = :F(EMIT_1) 

L = 75 

LINE  = GT  (SIZE  (LINE), 75)  ’ ' LINE  :S(EMIT_1) 

OUTSTR  = ' ' LINE  : (RETURN) 

DEC 

$1  = $1  - 1;  DEC  = .DUMMY  : (NRETURN) 

PUSH 

PUSH_POP  = LINK  (PUSH_POP,  X) ; PUSH  = . VALUE  (PUSH^POP)  .-(NRETURN) 

POP 

IDENT  (PU5H_POP)  : S (FRETURN) 

POP  = VALUE  (PUSH_POP);  PUSH_POP  = NEXT  (PUSH_POP)  : (RETURN) 

TOP 

TOP  = DIFFER  (PUSH_POP)  . VALUE  (PUSH..POP)  : F (FRETURN)  S (NRETURN) 

TID 

DIFFER (TID  = I DT<NAME  b ARITY>)  : S (RETURN) 

TJD  = LET  NEW (.  $ (LET  'ID'));  I DT<NAME  b ARITY>  = TID 

EMIT  (ARITY  ’ FNLIT  ’ TID  b NAME  '");  EQ  (ARITY,  0)  :S  (RETURN) 

PREDN<TID>  = ' P ' NEW(.  PID);  EMITCRECURS  ’ PREDN<TID>) 
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PREDT <T I D>  = ':R  ' PREDN<TID>  ' ENTER  ';  PREDLST  = LINK  (PREDLST,  T1 D) 
: (RETURN) 


NEW 

NEW  = JI;  JI  = JI  ♦ 1 : (RETURN) 

EMITPR 

5 ANCHOR  = 0 

PREDT<$PRED>  ’TRY'  RPOS(O)  = 'TRYLAST  ; ' : F (EMITFR_R) 

EMIT (PREDT  v JFRED>) ; 

EMITPR_R 

5ANCHOR  = I : (RETURN) 


* 

************************  SEMANTIC  ROUTINES  ********************************** 

* MAIN  ROUTINE  DEFINITION 
S_  : ($  0 P2_'  NAME)) 

* SEMANTIC  ROUTINES 

* 

P2_VAR 

T2  = ’V'  INSTR;  IDENT  (.OFFSET  ($T2)  ) : F (P2_VAR__REF) 

EQ  (NOCC  (JT2) , 1)  : S (P2_VDVAR) 

T3  = TYPE  ($T2)  ’OFF';  OFFSET($r2)  = JT3;  JT3  = JT3  + S(TYPE($T2)  'INC'); 
PUSHO  = FORTH (OFFSET (JT2)  b ARGNO  " U"  TYPE($T2)  'VAR  ', 

+ OFFSET  ($T2)  c t (IDENT (TYPE  tJT2),  ' L • ) 'LOCAL',  'VAR')  'ACCESS  , 

* OFFSET  ($T2)) 


+ : (RETURN) 

P2_VAR_REF 

PUSHO  = FORTH  (OFFSET  (fT2)  b ARGNO  " U"  TYPE($T2)  'REF  ', 

+ OFFSET  ($T2)  c t (I  DENT  (TYPE  ($T2) , ' l' ) 'LOCAL',  'VAR')  'ACCESS,  ') 

♦ : (RETURN) 

P2_VDVAR 

PUSHO  = FORTH  (,  "0  , ' VOIDACCESS  , ")  : (RETURN) 

P2_ATOM 

T1  = INSTR;  T2  = TI  D ( ' A' , T 1,  0) ; 

P'JSHO  = FORTH  (t  T2  b ARGNO  " UATOM  ",  t T2  C ATOMACCESS  , ") 

: (RETURN) 

P2_INT 

Tl  = INSTR; 

PUSHO  = FORTH  (Tl  b ARGNO  " UINT  ",  Tl  c "'  INTACCESS  , ") 

: (RETURN) 

P2_CONS l 
ARGNO  * 4 
: (RETURN) 
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P 2_ I NCL 

EL_CT  = EL_CT  + 1 
: (RETURN) 

P2_NIL 

PUSHO  = FORTH  ("'  NIL  " ARGNO  " UATOM  ",  NIL  , ' ATOMACCESS  , ") 

: (RETURN) 

P2_LISTI 

NEST  = NEST  + 1;  EL_CT  = 1;  PUSHO  = ARGNO;  ARGNO  = 0 
: (RETURN) 

P2_LI STF 

NEST  = NEST  - 1;  T2  = POP  () ; T1  = POP();  T3  = 'S'  NEW(.SID) 

HI  1 = I DENT  (HI  1)  OFF  (T2) ; LOl  = DI FFER  (OFF  (T2) ) OFF  (T2) 

HI  1 = I DENT  (HI  1)  OFF  (Tl) ; LOl  = DIFFER  (OFF  (Tl))  OFF(Tl) 

EMIT  ("HERE  " GOAL (Tl)  GOAL (T2) ) 

EMIT  ("HERE  [:  " MATCH  (Tl)  MATCH  (T2)  "RETURN  : ] ") 

EMIT  (" I ARRAY  " T3  " ’ CONS  , , , ") 

P2_LI STF_LP 

EQ  (EL_CT  = EL_CT  - 1,0)  : S (P2_LI STF_ND) 

Tl  = POPO 

HI  1 = I DENT  (HI1)  OFF(Tl);  LOl  = DI  FFER  (OFF  (Tl) ) OFF(Tl) 

EMIT  ("HERE  " GOAL  (Tl)  t T3  " , ' MOLACCESS  , ") 

EMIT  ("HERE  [:  " MATCH  (Tl)  b t T3  " 4 USKEL  RETURN  : ] ") 

T3  = 'S’  NEW (. SID);  EMIT  ("I ARRAY  " T3  " ' CONS  , , , ")  : (P2_LI STF_LP) 

P2_LI STF_ND 
ARGNO  = POPO 

PUSHO  = FORTH (t  T3  b ARGNO  ” USKEL  ",  t T3  c MOLACCESS  , ") 

: (RETURN) 

P\.J  C 

• NO  = ARGNO  + 4 
; (RETURN) 

P2_SKELI 

PUSHO  = INSTR;  PUSHO  = ARGNO;  ARGNO  = 0; 

NEST  = NEST  + 1 
: (RETURN) 

P2_SKELF 

NEST  = NEST  - 1;  T2  = ; T3  = ; T4  = (ARGNO  / 4)  + 1 
P2_SKELF_LP 

Tl  = POPO;  T2  = MATCH  (Tl)  T2;  T3  = GOAL  (Tl)  T3; 

HI  1 = I DENT  (HI1)  OFF(Tl);  LOl  = DI FFER  (OFF  (Tl) ) OFF  (Tl) 

GE  (ARGNO  = ARGNO  - 4,0)  : S (P2_SKELF_LP) 

ARGNO  = POPO; 

GT  (NEST,  0)  : S (P2_SKELF._N) 

PUSHO  = T4 

PUSHO  = FORTH  (T2,T3)  : (RETURN) 
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P2_SKELF_N 

T1  = 'S’  NEW  (.  SID);  EMITCHERE  ' T3);  EMIK'HERE  [:  ' T 2 ' RETURN  :]') 
T2  = POPO;  T3  = TI D ('  F ' , T2,  T4) ; 

EMIT  ("I  ARRAY  " Tl  " • " T3  M , , , ") 

T3  = (DIFFER  (HI  I)  EQ  (NEST,  1)  (HI  1 ♦ 4)  b LOl  ' INIT  ”) 

HI  1 = EQ  (NEST, 1) 

PUSHO  = FORTH (T3  t Tl  b ARGNO  " USKEL  ",  t Tl  c " ' MOLACCESS  , ") 

: (RETURN) 

P2_GOAL 

Tl  = GOAL  (POP  () ) ; T2  = POPO;  T3  = TI  D ( ' F ' , POP  0 , T2) ; 

5 ANCHOR  = 0 

P2_GOAL_RP  Tl  'VAR'  = ’GLOBAL’  : S (P2_GOAL_RP) 

^ANCHOR  = 1 

CLOUT  = CLOUT  "LIT  " PREDN<T3>  " CALL  [.  - Tl  " . J " 

: (RETURN) 

P2.CNEK 
FIN_HEAD  0 

CLOUT  = CLOUT  "NECK  " 

: (RETURN) 

P2.CFOOT 

CLOUT  = CLOUT  (ARGNO  * 4)  " FOOT  " 

: (RETURN) 

P2_CNC 

FIN_HEAD  0 

CLOUT  = CLOUT  LOFF  " NECKCUT  " : (RETURN) 

P2_CNCF 
F IN_HEAD  () 

CLOUT  = CLOUT  (ARGNO  * 4)  ’’  NECKCUTFOOT  " : (RETURN) 


P2_CNF 

FIN_HEAD  () 

CLOUT  = CLOUT  (ARGNO  * 4)  ’ NECKFOOT  ’ : (RETURN) 

P2_EOCL 

DONE  = ’YES’ 

EMIT  (CLOUT  ’;’) 

POP()  :F  (RETURN);  DUMP  (2) 

: (RETURN) 

P2_INI 

LOFF  = 16;  GOFF  = 0;  MID  = 0;  GID  = 0;  SID  = 0; 
CLOUT  = ’:  ’;  ARGNO  = 0;  NEST  = 0;  HI1  = 

: (RETURN) 

It 

ENDEF 


* 

*********************************************************************  ********  A 

* MAIN  PROGRAM  * 

****************************************************************************** 

OUTSTR  = " ' RDLN  2-  WNEXT  ! 2 WMODE  ! " 

OUTSTR  = "SC.  V GRMDF" 

**  READ  AND  COMPILE  A CLAUSE 
CMPL 

INSTR  : F (EOIN) 

* READ  THE  VARIABLE  LINES,  BUILD  VARIABLE  TABLE  "VART" 

VARL  = ; NVAR  = 0;  NGLOB  = 0 

VAR 

INSTR  BREAK  . T1  REM  . T3  : F (EOVAR) 

I DENT  ($  (T2  = ’v'  Tl))  : F (VAR_REF) 

VARL  = L INK  (VARL,  T2) 

$T 2 = VAR_REC(1,  (IDENT(T3,  'G')  'F','L'),) 

: (VAR) 

VAR.REF 

NE  (NOCC  ($T2)  = NOCC  ($T2)  + 1,  2)  : S (VAR.ETC) 

NVAR  = NVAR  + 1 

DIFFER (TYPE($T2),  ’ F ' ) : S (VAR_ETC) 

TYPE  ($T2)  = ’ G ' ; NGLOB  = NGLOB  + 1 : (VAR) 

VAR.ETC 

I DENT  (T3,  'G')  :F(VAR) 

NGLOB  = DIFFER (TYPE(JT2),  'G')  NGLOB  + 1 :F(VAR) 

TYPE  ($T2)  = 'G' 

: (VAR) 

EOVAR 

* READ  THE  INSTRUCTION  LINES  AND  CALL  THE  SEMANTIC  ROUTINES 
DONE  = 

DO_LOOP 

S_ (INSTR);  I DENT (DONE)  : S (DO_LOOP) 

* EMPTY  CONTENTS  OF  SYMBOL  TABLE 

EMPTY 

DIFFER  (VARL)  :F(CMPL);  $ (VALUE (VARL) ) = ; VARL  = NEXT  (VARL)  : (EMPTY) 

**  END  OF  INPUT,  OUTPUT  PREDICATE  CLAUSES 
EOIN 

1DENT  (PREDLST)  : S (OUT) 

EMITPR(. VALUE  (PREDLST));  PREDLST  = NEXT  (PREDLST)  : (EOIN) 

OUT 

OUTSTR  = "WMODE  OSET  S€. I GRMDF" 

END 

6.0  ERL  Templates 

*****  Event  Representation  Templates  and  auxiliaries  as  of  Jan  17,  1979.  ***** 
I The  top-level  procedure 


do  ([Tree]):-  build_ER (Tree,  ER) , t/pe_ER(ER). 
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I The  'build^ER'  procedure 

build_ER  (s  (Subj,  Vbgr,  Obj,  Compl,  Vmods),  temp  (Name,  HR) ):  - 
f ind_t_name  (Vbgr, Name) , 

construct  (Name, s (Subj, Vbgr, Obj,  Compl, Vmods),  ER) . 

I The  'construct'  procedure 

construct ('DEPLOY' , s (Subj, Vbgr, obj, Compl, Vmods) , [OBI, Dl, DTG] ) : - 
objectl  (Subj,  OBI), 
destinationl  (Vmods,  Dl) , 
construct (' DTG' , Vmods,  DTG) . 

construct  (' DTG' , Li st,  [T I , DT] ) : - 
time  (List, TI) , 
date  (List, DT) . 

construct (' ENROUTE' , s (Subj, Vbgr, Obj, Compl, Vmods) , [OBI,  MI,  Dl, DTG] ) : - 
objectl  (Subj,  OBI), 
mission  (s  (_, _, Obj, Compl,  Vmods) , MI), 
destinationl  (Vmods.  Dl), 
construct (' DTG' , Vmods,  DTG) . 

construct  (' PRECEDE' , s (Subj,  Obj,  _,_) , (El,  E2] ) : - 
build_ER(Subj, El), 
build_ER  (Obj,  E2) . 

construct (’AIRCRAFT',  np  (Det, LI,  Head, L2) , [EQ,  NA,  SUB,  SB,  SET]): - 
equipment  (LI,  Head,  EQ) , 
nationality  (LI, 'NATION',  NA)  , 
subordination (L2,  SUB) , 
stagingbase (L2,  SB), 
setspec  (Det,  SET) . 


construct (' DTG' , Vmods,  [TI, DT] ):  - timeCVmods,  TI),  date  (Vmods,  DT) . 

I Procedures  for  filling  in  template  slots 

date  (Vmods, slot ( ' Date= ' , [L, W,  Day,  Month,  Year] ) ) : - 

member  (pp  (L,  W,  date  (Day,  Month,  Year ) ) , Vmods) . 
date(_,  nil). 

destinationl  (Vmods, slot(' Destinations', Slot)):-  fill_slot  (Vmods,  [ ' TO ' ] , ' LOC' 

Slot) 

destination2  (X, Y):-  destinationl (X,  Y) . 
destination2  (_,nil). 

equipment  (List,  nnode(W,_),  slot  ('...  Equipments',  [List,  W])): - 
feat  (W,  'ACRAFT'). 
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I ■ 


national  1 ty  (List,  Feature, slot ('...  Nationality-'  W)):- 
rnember (nnode (W,  _),Llst),  feat  (V,  Feature  . 
na t i oua  1 i ty  (List,  Fea  t ure,  si ot  ( ' . . . Na t ional  1 ty  ' , W) ) : member  (W,  1.1  st ) , 

feat  (W,  Feat  ure"* . 

nat ional i ty (_ , , nil). 

object  1 (NP,  slot ('Object: Slot)):  test.nhead (NP, ’ ACRAFT' ) , 

construct  ('AIRCRAFT', NP,  Slot). 

set  spec  (Up  ( , , Num) , slot ('...  Number  ',Num)). 
set  spec  (_,  nil). 

stag lngbase  (Li s t , slot  ( ' . . . S tag  i ngba  se  '.Slot)):  fill  slot(List,  I'AT'J, 

'LOG', Slot'. 

stag!  ngbase  ( , nil). 

subord  1 na  t i on  ( List,  slot  ('  - ..  Subord  i na  t t on  - ' , SI  ot ) ) : fill  slot  (Li  s t , [ ' FROM'  ] , 

' SUBNLIM ' , Slot). 

subord  1 na  1 i on  (.  , nil). 

mission(s(  , , , , Vmods) , slot  ('Mission- ', Slot )) : 

fil l_slot  (Vmods,  ['AFTER',  ' FROM’,  ' IN',  'ON' ] , ' ACTY ' , Slot), 
mission ( , nil). 


1 1 me  (V mod  s , s 1 o t ( ' T l me  ' 
f lnd.  t 1 me (Vmods 
1 1 me  ( Vtnod s , s 1 o t ('  l l me  ' 
find  time (Vmods 
time (Vmods,  slot ('Time  ' 
fil 1 _sl o t (Vmods 
time (Vmods,  si ot ( 'Time  ' 
fill _s 1 o t (Vmods 
time  (_ , nl  1 ) . 

I Other  Procedures 


Slot)): 


1 ’AT', 'BETWEEN', 

'BY' 

Slot) ):  - 

1 'AT',  * BETWEEN ' , 

'BY' 

Slot)): 

CAT’,  'BETWEEN', 

'BY' 

Slot)): 

'TYMF', Slot). 


fil  l_slot  (List,  Prepllst,  Feature.  [1.1,  Prep,  NP]): 
member  (pp (LI,  Prep, NP) , List ) , 
member  (Prepa,  Prepllst),  1 exeq  (Prep,  Prepa) , 
tes  t _nliead  (NP,  Fea  I ure) . 
flll_slot(List,  Fea  t u r e, W) : 

member  Ova,  List',  lexeq(W,  Wa), 
feat (W, ' ADVB ' ) , 
feat  (W,  Feature). 

fill  slot  (NP,  Feature, NP):  test  nliead  (NP,  ' l.OC' ) . 

f 1 nd_  fea  t (W,  L,  Y) : member  (Y,  I.) , feat(W,Y). 

find_t  name(vg(  , , ,W),Natne): 

find,  feat  (W,  1'ARRIVE',  'DEPART',  'DEPLOY',  ' FNRODTF ' , 'FLIGHT', 


'LOCATE', 'PENETRATE', 'PRECEDE', 'RECOVER', 

'RETURN'],  Name). 

f ind_t_name  (nnode (W, _) , Name) : - f ind_feat  (W,  [ 'AIRCRAFT' ] , Name) . 

flnd_time  (List,  Preplist,  Feature,  [LI,  W,  L2] ):  - 
member (pp (LI,  W,  L2), List), 
member  (Wa,  Preplist),  lexeq(W,  Wa) , 
member (X,  L2) , 
feat (X,  Feature) . 

member  (X,  [X,  . . _] ) . 

member  (X,  . L]  ) : - member  (X,  L) . 

I Procedure  to  type  event  records  (type  'eaves  of  structure) 

type_ER  (temp  (N, L) ) : - typcr(O),  typatom  'Event:'),  typatom(N),  type_ER(L). 

type_ER  (slot  (S,  L) ) : - typcr(O),  typatomO,  type_ER(L). 

type_ER  ( [X, . . L] ) : - type_ER(X),  type_ER(L). 

type_ER  (nil). 

type_ER(X):-  typlex(X). 

type_ER(X):  typatom(X). 

type_ER (s (A, B, C, D) ) : - type_ER(A),  type_ER(B),  type_ER(C),  type_ER(D). 

type_ER (np (A, B, C, D) ) : type_ER(A),  type  ER(B),  type_ER(C),  type_ER(D). 

type_ER  (qp  (A,  B) ) : - type_ER(A),  type_ER(B). 

type_ER  (dp  (A,  B,  C) : - type_ER(A),  type_ER(B),  type_ER(C). 

type_ER  (nnode  (A,  B) ) : - type_ER(A),  type_ER(B). 

type_ER (v (A, B) ) : - type_ER(A),  type_ER(B). 

type_ER (pp (A,  B, C) ) : - type_ER(A),  type_ER(B),  type_ER(C). 

type_ER (p (A) ) : - type_ER(A). 

type_ER(vg  (A,  B,  C,  D) ) : - type_ER(A),  type_ER(B),  type_ER(C),  type_ER(D). 
type_ER (date (A, B,  C) ) : - type_ER(A),  type_ER(B),  type_ER(C). 

test_nhead  (np (_, _,  nnode (W,  _),_),  Feature) : - feat (W,  Feature) . 
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Appendix  B - Programming  in  Logic  with  the  Prolog  Language 

1 .0  Introduction 

The  following  paragraphs  are  extracted  from  a provisional  version  of  tiie  User's  Guide  to 
DECsystem-1 0 PROLOGS  and  provide  an  introduction  to  the  syntax  and  semantics  of  a 
certain  subset  of  logic  ("definite  clauses",  also  known  as  "Horn  clauses"),  and  indicates 
how  this  subset  forms  the  basis  of  Prolog. 

2.0  Syntax,  Terminology  and  Informal  Semantics 

2.1  Terms 

The  data  objects  of  the  language  are  called  terms.  A term  is  either  a constant,  a vari- 
able or  a compound  term. 

The  constants  include  integers  such  as:- 

0 1 999  -512 

17  17 

In  DECsystem-10  Prolog,  integers  are  restricted  to  the  range  -2  to  2 -1,  i.e. 

-131072  to  131071.  Besides  the  usual  decimal,  or  base  10,  notation,  integers  may  also 
be  written  in  any  base  from  2 to  9,  of  which  base  2 (binary)  and  base  8 (octal)  are 
probably  the  most  useful.  As  an  example  of  the  notation  used:- 

16  2’1 1 1 1 8’1  7 

all  represent  the  Integer  fifteen. 

Constants  also  include  atoms  such  as:- 

a void  = :=  ’Algol-68’  [] 

The  symbol  for  an  atom  can  be  any  sequence  of  characters,  which  should  be  written  in 
quotes  if  there  is  possibility  of  confusion  with  other  symbols  (such  as  variables. 
Integers).  As  in  conventional  programming  languages,  constants  are  definite  elementary 
objects,  and  correspond  to  proper  nouns  In  natural  language. 

Variables  are  distinguished  by  an  initial  capital  letter  or  by  the  initial  character  eg. 

X Value  A A1  _3  _RESU!.T 

If  a variable  is  only  referred  to  once,  it  does  not  need  to  be  named  and  may  be  written 
as  an  "anonymous"  variable  indicated  by  a single  underline  character. 

A variable  should  be  thought  of  as  standing  for  some  definite  but  unidentified  object. 
This  is  analogous  to  the  use  of  a pronoun  in  natural  language.  Note  that  a variable  is  not 
simply  a writeable  storage  location  as  in  most  programming  languages;  rather  it  is  a local 
name  for  some  data  object,  cf.  the  variable  of  pure  Lisp  and  identity  declarations  in 
Algol-68. 

The  structured  data  objects  of  the  language  are  the  compound  terms.  A compound  term 
comprises  a functor  (called  the  principal  functor  of  the  term)  and  a sequence  of  one  or 


1*  This  version  was  prepared  by  Luis  Moniz  Pereira  of  Divisao  de  Informatica 
Laboratorio  National  de  Engenharia  Civil,  Lisbon,  and  Fernando  C.N.  Pereira,  and 
David  H.  D.  Warren,  both  at  the  Department  of  Artificial  Intelligence,  University  of 
Edinburgh,  England,  and  Issued  April  1978. 


B-l 


more  terms  called  arguments.  A functor  Is  characterized  by  its  name,  which  is  an  atom, 
and  its  arity  or  number  of  arguments.  For  example,  the  compound  term  whose  functor  is 
named  ’point’  of  arity  3,  with  arguments  X,  Y and  Z,  is  written:- 

point  (X.y.Z) 

Note  that  an  atom  Is  considered  to  be  a functor  of  arity  0. 

Functors  are  generally  analogous  to  common  nouns  in  natural  language.  One  may  think  of 
a functor  as  a record  type  and  the  arguments  of  a compound  term  as  the  fields  of  a 
record.  Compound  terms  are  usefully  pictured  as  trees.  For  example,  the  term:- 

s(np(john),vp(v(likes),np(mary))) 

would  be  pictured  as  the  structure:- 


john  v np 


likes  mary 

Sometimes  it  is  convenient  to  write  certain  functors  as  operators  - 2-ary  functors  may 
be  declared  as  infix  operators  and  1 -ary  functors  as  prefix  or  postfix  operators.  Thus 
it  is  possible  to  write,  eg. 

x+y  ( p;o ) x<y  *x  p-, 

as  optional  alternatives  to:- 

+(X,V)  ;(P,Q)  <(X,y)  +(X)  ;(P) 

An  important  class  of  data  structures  are  the  lists.  These  are  essentially  the  same  as 
the  lists  of  Lisp.  A list  either  is  the  atom:- 

[] 

representing  the  empty  list,  or  is  a compound  term  with  functor  and  two  arguments 
which  are  respectively  the  head  and  tail  of  the  list.  Thus  a list  of  the  first  three  natural 
numbers  is  the  structure:- 


which  could  be  written,  using  the  standard  syntax,  as:- 
.(1,.(?,.(3,[]))) 

but  which  is  normally  written,  in  a special  list  notation,  as:- 
[1,2.3] 

The  special  list  notation  in  the  case  when  the  tail  of  a list  is  a variable  is  exemplified 
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by:- 


{ a,b,..l  ] 
representlng:- 


For  convenience,  a further  notational  variant  is  allowed  for  lists  of  integers  which 
correspond  to  ASCII  character  codes.  Lists  written  in  this  notation  are  called  strings. 
An  example  ls:- 

"DECsystem- 1 0“ 

which  represents  exactly  the  same  list  as:- 

[68,69,67,1  16,121,1  16.1  16,101,109,45,49,48] 

2.2  Programs 

A fundamental  unit  of  a logic  program  is  the  goal  or  procedure  call.  Examples  are-.- 

gives(tom, apple, teacher)  reverse([  1 ,2.3],L)  X<V 

A goal  is  merely  a special  kind  of  term,  distinguished  only  by  the  context  in  which  it 
appears  in  the  program.  The  (principal)  functor  of  a goal  is  called  a predicate.  It 
corresponds  roughly  to  a verb  in  natural  language,  or  to  a procedure  name  in  a conven- 
tional programming  language. 

A logic  program  consists  simply  of  a sequence  of  statements  called  sentences,  which  are 
analogous  to  sentences  of  natural  language.  A sentence  comprises  a head  and  a body. 
The  head  either  consists  of  a single  goal  or  is  empty.  The  body  consists  of  a sequence 
of  .zero  or  more  goals  (i.e.,  it  too  may  be  empty.  Ihe  body  consists  of  a sequence  of 
zero  or  more  goals  (i.e.,  it  too  may  be  empty).  If  the  head  is  not  empty,  the  sentence  is 
called  a clause. 

If  the  body  of  a clause  is  non-empty,  the  clause  is  called  a non-unit  clause,  and  is  writ- 
ten in  the  form:- 

P Q,  R,  S. 

where  P is  the  head  goal  and  Q,  R and  S are  tire  goals  which  make  up  the  body.  We  can 
read  such  a clause  either  declaratively  as:- 

"P  is  true  if  Q and  R and  S are  true." 

or  procedurally  as:- 

"To  satisfy  goal  P,  satisfy  goals  Q,  R and  S " 

If  the  body  of  a clause  is  empty,  the  clause  is  called  a unit  clause,  and  is  written  in  the 
form:- 

P. 

where  P is  the  head  goal.  Wo  interpret  this  declaratively  as  - 


P is  true. 


and  procedurally  as  — 

"Goal  P is  satisfied." 

A sentence  with  an  empty  head  is  called  a directive,  of  which  the  most  important  kind  is 
called  a question  and  is  written  in  the  form.— 

?-  P,  0. 

where  P and  Q are  the  goals  of  the  body.  Such  a question  is  read  declaratively  as  — 

"Are  P and  Q true?" 
and  procedurally  as:- 

"Satisfy  goals  P and  Q." 

Sentences  generally  contain  variables.  Note  that  variables  in  different  sentences  are 
completely  independent,  even  if  they  have  the  same  name  — i.e.,  the  "lexical  scope"  of 
a variable  is  limited  to  a single  sentence.  Each  distinct  variable  in  a sentence  should  be 
interpreted  as  standing  for  an  arbitrary  entity,  or  value.  To  illustrate  this,  here  are  some 
examples  of  sentences  containing  variables,  with  possible  declarative  and  procedural 
readings:- 

(1)  employed(X)  — ernploys(Y.X). 

"Any  X is  employed  it  any  Y employs  X." 

"To  find  whether  a person  X is  employed, 
find  whether  any  Y employs  X." 

(2)  derivative(X,X,1 ). 

"For  any  X,  the  derivative  of  X with  respect  to  X is  1." 

"The  goal  of  finding  a derivative  for  the  expression  X with 
respect  to  X itself  is  satisfied  by  the  result  1." 

(3)  ?-  ungulate(X),  aquatic(X). 

"Is  it  true,  for  any  X,  that  X is  an  ungulate  and  X is 
aquatic?" 

"Find  an  X which  is  both  an  ungulate  and  aquatic." 

In  any  program,  ttie  procedure  for  a particular  predicate  is  the  sequence  of  clauses  in 
the  program  whose  head  goals  have  that  predicate  as  principal  functor.  For  example, 
the  procedure  for  a ternary  predicate 

concatenate([X,..l  1 ],L2,[X,..L3])  concatenate  (LI,  L2,  13). 
concatenate  ([],L,l). 

where  ’concatenated  1 ,L2,L3)'  means  "tire  list  LI  concatenated  with  the  list  L2  is  the 
list  L3". 
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Certain  predicates  are  predefined  by  built-in  procedures  supplied  by  the  Prolog  system. 
Such  predicates  are  called  evaluable  predicates. 

As  we  have  seen,  the  goals  in  the  body  of  a sentence  are  linked  by  the  operator 
which  can  be  interpreted  as  conjunction  ("and").  It  is  sometimes  convenient  ’o  use  an 
additional  operator  standing  for  disjunction  ("or").  (The  precedence  of  is  such  that 
it  dominates  ' but  is  dominated  by  ’:-').  An  example  is  the  clause:- 

grandfather(X.Z) 

(mother(X.Y);  father(X,Y)),  father(Y.Z). 

which  can  be  read  as:- 

"For  any  X,  Y and  Z, 

X has  Z as  a grandfather  if 

either  the  mother  of  X is  Y or  the  father  of  X is  Y, 
and  the  father  of  Y is  Z. 

Such  uses  of  disjunction  can  always  be  eliminated  by  defining  an  extra  predicate  — for 
instance  the  previous  example  is  equivalent  to-.- 

grandfather(X.Z)  parent(X.Y),  father  (Y,Z). 
parent(X.Y)  mother(X,Y). 
parent(X.Y)  father(X.Y). 

— and  so  disjunction  will  not  be  mentioned  further  in  the  following,  more  formal,  descrip- 
tion of  the  semantics  of  clauses. 

3.0  Declarative  And  Procedural  Semantics 

The  semantics  of  definite  clauses  should  be  fairly  clear  from  the  informal  interpretations 
already  given.  However,  it  is  useful  to  have  a precise  definition.  The  declarative  seman- 
tics of  definite  clauses  tells  us  which  goals  can  be  considered  true  according  to  a given 
program,  and  is  defined  recursively  as  follows. 

A goal  is  true  if  it  is  the  head  of  some  clause  Instance  and  each  of  the  goals  (if  any) 
In  the  body  of  that  clause  instance  is  true,  where  an  instance  of  a clause  (or  term)  is 
obtained  by  substituting,  for  each  of  zero  or  more  of  its  variables,  a new  term  for  all 
occurrences  of  the  variable. 

For  example,  if  a program  contains  the  preceding  procedure  for  'concatenate',  then  the 
declarative  semantics  tells  us  that:- 

concatenate([a],[b],[a,b]) 

Is  true,  because  this  goal  is  the  head  of  a certain  instance  of  the  first  clause  for  ’con- 
catenate’, namely, 

concatenate([a],[b],[a,b])  concatenate^ J,[ b],[b]). 

and  we  know  that  the  only  goal  in  the  body  of  this  clause  instance  is  true,  since  it  is  an 
instance  of  the  unit  clause  which  is  the  second  clause  for  ’concatenate’. 

Note  that  the  declarative  semantics  makes  no  reference  to  the  sequencing  of  goals 
within  the  body  of  a clause,  nor  to  the  sequencing  of  clauses  within  a program.  This 
sequencing  information  is,  however,  very  relevant  for  the  procedural  semantics  which 
Prolog  gives  to  definite  clauses.  The  procedural  semantics  defines  exactly  hov.'  the  Pro- 
log system  will  execute  a goal,  and  the  sequencing  information  is  the  means  by  which 
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the  Prolog  programmer  directs  the  system  to  execute  his  program  in  a sensible  way. 
The  effect  of  executing  a goal  is  to  enumerate,  one  by  one,  Its  true  instances.  Here 
then  is  an  informal  definition  of  the  procedural  semantics. 


To  execute  a goal,  the  system  searches  for  the  first  clause  whose  head  matches  or 
unifies  with  the  goal.  The  unit ication  process  [Robinson  1966]  finds  the  most  gen- 
eral common  instance  of  the  two  terms,  which  is  unique  if  it  exists.  If  a match  is 
found,  the  matching  clause  instance  is  then  activated  by  executing  in  turn,  from  left 
to  right,  each  of  the  goals  (if  any)  in  its  body.  If  at  any  time  the  system  fails  to  find 
a match  for  a goal,  it  backtracks,  i.e.,  it  rejects  the  most  recently  activated  clause, 
undoing  any  substitutions  made  by  the  match  with  the  head  of  the  clause.  Next  it 
reconsiders  the  original  goal  which  activated  the  rejected  clause,  and  tries  to  find  a 
subsequent  clause  which  also  matches  the  goal. 


For  example,  if  we  execute  the  goal  expressed  by  the  question:- 
?-  concatenated, Y, [a.b]). 

we  find  that  it  matches  the  head  of  the  first  clause  for  ’concatenate',  with  X instan- 
tiated to  [a, ..XI).  The  new  variable  XI  is  constrained  by  the  new  goa'  produced,  which 
Is  the  recursive  procedure  call:- 


concatenate(X1  ,Y,[b]) 

Again  this  goal  matches  the  first  clause,  instantiating  XI  to  [b,..X2],  and  yielding  the 
new  goal:- 

concatenate(X2,Y,[]) 

Now  this  goal  will  only  match  the  second  clause,  instantiating  both  X2  and  Y to  [J.  Since 


there  are  no  further  goals  to  be  executed,  we  have  a solution:- 


X = [a,b] 
Y = [] 


e , a true  instance  of  the  original  goal  is : - 


concatenate([a,b],[],f  a.b]) 

If  this  solution  is  rejected,  backtracking  will  generate  the  further  solutions:- 


X = [al 
Y = [b] 


X = [) 

Y = [a.b] 


In  that  order,  by  re-matching,  against  the  second  clause  for  ’concatenate’,  goals  already 
solved  once  using  the  first  clause. 


3.1  Prolog  Control  Mechanisms 


As  is  evident  from  the  above,  Prolog  provides  a remarkably  simple  form  of  control,  which 
suffices  for  many  practical  applications  of  logic  programming.  This  point  was  first  real- 
ized at  Marseille  and  is  the  basis  of  the  programming  language  Prolog  developed  there 


If  we  think  back  to  the  declarative  semantics  of  clauses,  it  is  clear  that  the  order  of  the 
goals  in  a clause  and  the  order  of  the  clauses  themselves  are  both  irrelevant  to  the 
declarative  interpretation.  However,  these  orderings  are  generally  significant  in  Prolog, 


. J 


as  they  constitute  the  main  control  information 


When  the  Prolog  system  is  executing  a procedure  call,  the  clause  ordering  determines 
the  order  in  which  the  different  entry  points  of  the  procedure  are  tried  The  goal  ,>rd>  eng 
fixes  the  order  in  which  the  procedure  calls  in  a clause  are  executed.  The  "nmiln  :ive" 
effect  of  a Prolog  computation  arises  from  the  process  of  “matching"  a procedure  call 
against  a procedure  entry  point. 
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Appendix  C - MATRES  <1  Lexicon 


1.0  Lexicon 

LEXICON 

FEATURE 

1DIG 

FEATURE 

2DIG 

FEATURE 

4DIG 

FEATURE 

ACRAFT 

FEATURE 

ADVB 

FEATURE 

ADJ 

FEATURE 

NOMZ 

FEATURE 

ACTVTY 

FEATURE 

ALT 

FEATURE 

ARRIVE 

FEATURE 

BE 

FEATURE 

BEFORE 

FEATURE 

COMMUNICATION 

FEATURE 

CONFIRM 

FEATURE 

CONTINUE 

FEATURE 

CONJ 

FEATURE 

COPULA 

FEATURE 

DEPART 

FEATURE 

DEPLOY 

FEATURE 

DIR 

FEATURE 

ART 

FEATURE 

EOS 

FEATURE 

EVAL 

FEATURE 

EMOD 

FEATURE 

ENROUTE 

FEATURE 

FLIGHT 

FEATURE 

GO 

FEATURE 

HEAD 

FEATURE 

HAVE 

FEATURE 

IMPACT 

FEATURE 

INTRANS 

FEATURE 

LOC 

FEATURE 

LOCATE 

FEATURE 

LAND 

FEATURE 

LAUNCH 

FEATURE 

MISSILE 

FEATURE 

MO 

FEATURE 

MODAL 

FEATURE 

NUM 

FEATURE 

NUMMOD 

FEATURE 

NATION 

FEATURE 

NATO 

FEATURE 

N 

FEATURE 

OBSERVE 

FEATURE 

OP.D 

FEATURE 

PASTP 

C-l 


FEATURE 

PL 

FEATURE 

POSPRO 

FEATURE 

PRESP 

FEATURE 

PRO 

FEATURE 

PRTCL 

FEATURE 

PREP 

FEATURE 

PENETRATE 

FEATURE 

QUANT 

FEATURE 

RE-ENTER 

FEATURE 

REF 

FEATURE 

RETURN 

FEATURE 

RELPRO 

FEATURE 

SATELLITE 

FEATURE 

SCONJ 

FEATURE 

SCRAF1 

FEATURE 

SERVICE 

FEATURE 

SG 

FEATURE 

SUBNUM 

FEATURE 

SUPER 

FEATURE 

STAGE 

FEATURE 

THATCOMP 

FEATURE 

TJPE 

FEATURE 

TYME 

FEATURE 

TENSED 

FEATURE 

TOCOMP 

FEATURE 

TRANS 

FEATURE 

UNIT 

FEATURE 

VB 

FEATURE 

VPASSIVE 

( AIR  FORCE)  [ N ] . ; 

( AIR  REGIMENT)  [ N ] .; 

( AIR  SPACE)  ( N LOC  ] . ; 

( AL  JAGHBUB)  [ N LOC  ] . ; 

( ALL  OF)  I QUANT  ] . ; 

( A MINIMUM  OF)  [ NUMMOD  ] 

( ARABIAN  SEA)  [ N LOC  ] 

( AS  FAR)  [ PREP  EMOD  ] 

( AS  MANY  AS>  [ NUMMOD  J . ; 

C AT  LEAST)  [ NUMMOD  ] . ; 

( AT  MOST)  [ NUMMOD  ] 

( BARENTS  SEA)  [ N LOC  ] 

( BOMBER  CORPS)  [ N ] 

( BUFF  A)  [ N NATO  ACRAFT  ] 

( BUFF  B)  [ N NATO  ACRAFT  I . ; 

( BUFF  C)  [ N NATO  ACRAFT  ) . ; 

( BUFF  D)  [ N NATO  ACRAFT  ] . ; 

( BUFF  0)  [ N NATO  ACRAFT  ] 

( CAPE  VERDE  ISLANDS)  [ N LOC  ] 
( COMMAND  AND  CONTROL)  [ ADJ  ] 

( CONTROL  AND  REPORTING)  [ ADJ 


( EAST  OF)  [ PREP  I 
( GULF  OF  ADEN)  [ N LOC  ] . ; 

( GULF  OF  AQABA)  [ N LOC  J 
( HEAVY  BOMBERS)  [ N PL  ACRAFT  ] . ; 
( HEAVY  BOMBER)  [ N SG  ACRAFT  ] . ; 

( IN  CONJUNCTION  WITH)  [ PREP  ] 

( IN  CONNECTION  WITH)  [ PREP  3 
( IN  REACTION  TO)  [ PREP  ] 

( INDIAN  OCEAN)  [ N LOC  J . ; 

( LACCADIVE  ISLANDS)  [ N LOC  3 
( MALDIVE  ISLANDS)  [ N LOC  ] 

C MANY  OF)  [ QUANT  J . ; 

( MEDIUM  BOMBER)  [ N SG  ACRAFT  ] . ; 
( MEDIUM  BOMBERS)  [ N PL  ACRAFT  ] . 
( MIRAGE  III)  [ N TJPE  ACRAFT  ] 

( MOST  OF)  [ QUANT  ] . ; 

( NATIONAL  GUARDS)  [ N ] 

( NATIONAL  GUARD)  C N ] . ; 

( NONE  OF)  [ QUANT  J 
( NORTH  OF)  [ PREP  ] 

( NORTHEAST  OF)  [ PREP  ] 

( NORTHWEST  OF)  [ PREP  J 
( RED  SEA)  [ N LOC  ] 

( SAUDI  ARABIAN)  [ ADJ  NATION  ] 

( SEA  OF  CRISES)  [ N LOC  ] 

( SEYCHELLE  ISLANDS)  [ N LOC  ) 

( SEYCHELLE  ISLAND  CHAIN)  [ N LOC  ] 
( SMALL  SCALE)  [ ADJ  ] 

( SOME  OF)  ( QUANT  ] 

( SOUTH  AFRICAN)  [ ADJ  NATION  ] 

( SOUTH  OF)  l PREP  ] 

( SOUTHEAST  OF)  [ PREP  ] 

( SOUTHWEST  OF)  [ PREP  ] 

( SOVIET  UNION)  [ N LOC  NATION  ] 

( ST  HELENA)  I N LOC  J 
( TEST  RANGE)  [ N LOC  ] 

( VEST  OF)  l PREP  ] . ; 

( WHITE  SEA)  [ N LOC  ] 

A [ ART  3 

A3 13  [ N SUBNUM  ] 

AA  [ ADJ  ] 

ABOUT  [ ADV'B  EVAL  ] . ; 

ACFT  [ N ACRAFT  ] 

ACTIVE  f ADJ  ACTVTY  3 
ACTIVITY  I N NOM2  3 
ACTY  I N NOMZ  ] 

ADDITIONAL  [ ADJ  REF  3 . ; 

ADX  I N NOMZ  3 
AD2  l N LOC  3 . J 
AFRICAN  { ADJ  ] 


AFTER  [ PREP  TYME  SCONJ  ] . ; 

AGAINST  [ PREP  EMOD  ] 

AIR-TO-SURFACE  [ ADJ  ] 

AIR  ( N ] 

AIRBORNE  [ ADJ  FLIGHT  ] 

AIRCRAFT  [ N ACRAFT  J 
ALEXANDRIA  [ N LOC  ] . ; 

ALL  [ QUANT  ] 

ALONG  [ PREP  EMOD  ] . ; 

ALTITUDE  [ N SG  ALT  ] 

ALTITUDES  [ N PL  ALT  ] 

AN  [ ART  ] 

AND  l CONJ  ] 

APPROXIMATELY  [ ADYB  EVAL  ] 

AFR  [ N TYME  MO  ] 

APRIL  l N TYME  MO  ] 

ARE  [ BE  COFULA  TENSED  ] . ; 

AREA  [ N SG  LOC  ] . ; 

AREAS  [ N PL  LOC  ] 

ARRIVED  [ YB  PASTP  ARRIVE  ] [ VB  TENSED  ARRIVE  ] 
AS  [ PRTCL  ] . ; 

ASSOCIATED  [ ADJ  ] . ; 

ASM  [ ADJ  ] 

ASV  [ ADJ  ] . ; 

AT  [ PREP  EMOD  TYME  ] . ; 

ATLANTIC  [ N LOC  ] 

AUG  [ N TYME  MO  ] . ; 

AUGUST  [ N TYME  MO  ] . ; 

AUXILIARY  [ ADJ  ] 

AVIATION  [ N NOMZ  j 
A-4  [ N TJPE  ACRAFT  ] 

B-75  [ N TJPE  ACRAFT  ] 

B-75S  [ N TJPE  ACRAFT  ] 

B-60  [ N TJPE  ACRAFT  ] 

B-60'S  [ N TJPE  ACRAFT  ] 

B-61  [ N TJPE  ACRAFT  ] 

B-63  [ N TJPE  ACRAFT  ] 

B-63'S  [ N TJPE  ACRAFT  } . ; 

B-63S  [ N TJPE  ACRAFT  ] 

B-67S  [ N TJPE  ACRAFT  ] 

B-80  [ N TJPE  ACRAFT  ] 

B-TYPE  [ N TJPE  ACRAFT  ] . ; 

B-TYPES  [ N TJPE  ACRAFT  ] . ; 

BACTERIOLOGICAL  [ ADJ  ] 

BAIKONUR  [ N LOC  ] 

BARFLY  [ N NATO  ACRAFT  ] . ; 

BASE  [ N LOC  ] . ; 

BC254  [ N SUBNUM  ] 

BE  [ BE  COPULA  ] . ; 

BEACON  [ N NATO  ACRAFT  ] . ; 
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BEAGLE  [ N NATO  ACRAFT  ] . ; 

BED  [ N ] 

BEEN  I BE  COPULA  PASTP  ] 

BEETLES  [ N ] . ; 

BEFORE  [ PREP  TYME  SCONJ  ] 

BEING  [ BE  COPULA  PRESP  ] 

BETWEEN  [ FREP  EMOD  TYME  ] . ; 

BOMBER  [ N SG  ACRAFT  ] . ; 

BOMBERS  [ N PL  ACRAFT  ] 

BORDER  [ N LOC  ] . ; 

BOUNDED  [ ADJ  ] 

BUFF  [ N NATO  ACRAFT  ] . ; 

BUJUMBURA  [ N LOC  ] . ; 

BUTTER  [ N NATO  ACRAFT  ] . ; 

BY  [ PREP  EMOD  TYME  ] . ; 

CAPETOWN- BAS ED  { ADJ  ] 

CAPETOWN  [ N LOC  ] . ; 

CAPSULE  [ N ] . ; 

CENTER  [ N LOC  ] . ; 

CENTRAL  [ ADJ  ] . ; 

COAST  [ N LOC  ] 

COLLECTION  [ N NOMZ  ] 

COMBAT  [ N NOMZ  ] 

COMBATANT  IN].; 

COMBATANTS  I N FL  ] . ; 

COMMUNICATION  [ N ] 

COMPLEX  [ N LOC  ] 

CONDUCTING  [ VB  TRANS  PRESP  FLIGHT  ] 

CONDUCTED  [ VB  TRANS  PASTP  FLIGHT  ] { VB  TRANS  TENSED  FLIGHT  ] . 
CONFIRMED  [ VB  TRANS  PASTP  CONFIRM  ] I VB  TRANS  TENSED  CONFIRM  ] 
CONGO  I N LOC  ] . ; 

CONTAINING  [ VB  TRANS  PRESP  ] . ; 

CONTINUED  [ VB  TRANS  PASTP  ] [ VB  TRANS  TENSED  ] 

CONTINUING  [ VB  TRANS  PRESP  DIR  CONTINUE  ] 

CONTINENTAL  [ ADJ  3 
CONTROLLER  IN] 

CORNER  IN].; 

COSMODROME  [ N LOC  ] . ; 

COSMOS-605  [ N SATELLITE  ] .; 

COSMOS-629  I N SATELLITE  ] .; 

COSMOS-706  [ N SATELLITE  ] .; 

COSMOS-722  [ N SATELLITE  ] .; 

CRAFT  [ N SCRAFT  ] .; 

CURRENTLY  [ ADVB  REF  TYME  ] . ; 

DAMASCUS  [ N LOC  ] .; 

DEC  [ N TYME  MO  ] .; 

DECEMBER  I N TYME  MO  ] . ; 

DEFENSIVE  [ ADJ  ] . ; 

DELTA-CLASS  I ADJ  ] . ; 

DEPARTED  I VB  TRANS  PASTP  DEPART  ] f VB  TRANS  TENSED  DEPART  1 . ; 
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DEPLOYED  l VB  TRANS  PASTP  DEPLOY  ] [ VB  TRANS  TENSED  DEPLOY  ] 

DEPLOYMENTS  ! N PL  NOMZ  1 
DESTINATION  l N J 
DIVISION  IN].; 

DJ I BOUT  1 l N LOC  ] . ; 

DOWNED  [ VB  TRANS  PASTP  ] [ VB  TRANS  TENSED  ] 

DURING  [ PREP  EMOD  TYME  J . ; 

E16S1D  [ N SUBNUM  J 

EABC  [ N NATION  I 

EAFAF  [ N NATION  SERVICE  ] 

EARLIER  I ADVB  TYME  REF  ] 

EARLY  l ADVB  TYME  J [ ADJ  TYME  J . ; 

EARTH  [ N ] . ; 

FAST  I ADVB  DIR  ] [ ADJ  ] 

EASTERN  [ ADJ  ] . ; 

EGYPTIAN  [ ADJ  NATION  ] 

EIGHT  [ NUM  ] 

ENROUTE  I ADJ  TOCOMP  ENROUTE  ] . ; 

ENTEBBE  [ N LOC  ] . ; 

EQUIPMENT  [ N ] . ; 

FTBF  [ N LOC  ] . ; 

ETHIOPIAN  [ADJ  ] 

EXERCISE  I N NOMZ  ] 

F-4  [ N TJPE  ACRAFT  ] 

F-4E  l N TJPE  ACRAFT  J 
F-SE  l N TJPE  ACRAFT  ] 

FEB  [ N TYME  MO  ] . ; 

FEBRUARY  [ N TYME  MO  ] . ; 

FERRY  [ N ] . ; 

FIGHTER  BOMBERS  l N PL  ACRAFT  ] 

FIGHTER  [ N SG  ACRAFT  ] 

FIGHTERS  I N PL  ACRAFT  ] 

FIRED  [ VB  TRANS  PASTP  LAUNCH  J [ VB  TRANS  TENSED  LAUNCH  ] 
FLEET  [N]  . ; 

FLEW  l VB  TRANS  TENSED  DIR  PLIGHT  ] 

FLIGHT  [ N SG  NOMZ  ] 

FLIGHTS  1 N PL  NOMZ  ] 

FLOGGER  L N NATO  ACRAFT  ] . ; 

FODDER  [ N NATO  ACRAFT  ] . ; 

FOLLOWING  l SCONJ  I 
FOR  l PREP  ] . ; 

FOUR  l NUM  ] . ; 

FRESCO  [ N NATO  ACRAFT  ] . ; 

FROM  [ PREP  EMOD  TYME  ] 

GENERAL  I ADJ  ] . ; 

GROUP  IN]  . ; 

GULII  BASED  t ADJ  1 . ; 

GlILU  t N LOC  ] . ; 

HAD  [ HAVE  TENSED  ] l VB  TRANS  PASTP  ] [ VB  TRANS  TENSED  1 

HAIFA  I N LOC  1 


HAS  L HAVE  TENSED  ] [ VB  TRANS  TENSED  ] 

HAVE  [ HAVE  J [ HAVE  TENSED  ] l VB  TRANS  ] [ VB  TRANS  TENSED  J . 
HAVING  [ VB  TRANS  PRESP  J 
HEADING  l VB  PRESP  DIR  HEAD  ] 

HERMETICALLY  [ ACVB  ] 

HOMEBASE  l N LOG  ] 

HOUR  [ N TYME  UNIT  ] 

HOURS  l N TYME  UNIT  ] 

HR  [ N TYME  UNIT  J 
II.-28  [ N TJPE  A CRAFT  ] 

IN  [ PREP  EMOD  ] 

INDEPENDENT  [ ADJ  ] 

INFORMED  l VB  TRANS  PASTP  THATCOMP  COMMUNICATION  J 
[ \B  TRANS  TENSED  THATCOMP  COMMUNICATION  ] 

INTELLIGENCE  I N NOM2  ] 

INTO  [ PREP  EMOD  ] 

INVOLVING  [ VB  TRANS  PRESP  ] 

IRANIAN  [ ADJ  NATION  ] 

IS  [ BE  COPULA  TENSED  ] . ; 

ISRAEL  [ N LOG  NATION  ] 

ISRAELI  [ ADJ  NATION  ] 

JAN  [ N TYME  MO  ] . ; 

JANUARY  I N TYME  MO  ] . ; 

JUBA  [ N LOG  J . ; 

JUN  [ N TYME  MO  ] . ; 

JUNE  [ N TYME  MO  ] . ; 

JUL  [ N TYME  MO  J . ; 

JULY  I N TYME  MO  ] . ; 

JUST  [ ADVB  ] . ; 

KATHMANDU  [ N LOC  ] 

KB252  [ N SUBNUM  ] 

KE843  [ N SUBNUM  ] 

KENYA  [ N LOC  NATION  J 

KENYAN  [ ADJ  NATION  ] 

KF1R  [N  TJPE  ACRAFT  ] 

KILOMETERS  [ N PL  UNIT  ] 

KINSHASA  [ N LOC  ] 

KM  t N SG  UNIT  J 
KMS  I N Pl.  UNIT  ] 

LACCADIVES  [ N LOC  ] 

LANDED  [ VB  PASTP  LAND  ] I VB  TENSED  LAND  ] 

LANDMASS  [ N LOC  J 
LAST  [ ADJ  j . ; 

LATE  [ ADJ  TYME  .1  . ; 

LAUNCHED  l VB  TRANS  PASTP  LAUNCH  J [ VB  TRANS  TENSED  LAUNCH  ] . ; 
LEBANON  [ N LOC  NATION  ] 

LIBYAN  [ ADJ  NATION  J 
LIVING  [ ADJ  ] 

LOCATED  [ ADJ  VB  TRANS  PASTP  LOCATE  I I VB  TRANS  TENSED  LOCATE  ] 
LUNA  23  [ N SATELLITE  1 


LUNAR  [ ADJ  ] . ; 

MALAGASY  l N LOC  J 
MANEUVERABLE  [ ADJ  ] . ; 

MANNED  [ ADJ  ] 

MANY  [ QUANT  ] . ; 

MAR  [ N TYME  MO  ] . ; 

MARCH  [ N TYME  MO  J . ; 

MARITIME  [ ADJ  ] 

MASSAWa  [ N LOC  ] 

MAURITIUS  l N LOC  ] 

MAY  [ MODAL  ] I N TYME  MO  ] . ; 

METERS  [ N PL  UNIT  1 
MID  [ ADJ  ] . ; 

MIG-17  [ N TJPE  ACRAFT  ] . ; 

MIG-21  [ N TJPE  ACRAFT  ] . ; 

MIG-23  [ N TJPE  ACRAFT  ] 

MILES  I N UNIT  ] . ; 

MILITARY  [ ADJ  ] 

MISSILE  [ N MISSILE  ] 

MISSION  [ N NOMZ  ] . ; 

ML-28  I N TJPE  ACRAFT  ] . ; 

MOGADISHU  { N LOC  ] 

MOMBASA-BASED  [ ADJ  ] . ; 

MOMBASA  I N LOC  J . ; 

MONTH  [ N TYME  ] . ; 

MORNING  [ N TYME  ] 

MOST  [ QUANT  ] . ; 

MUSHROOM  [ N ] . ; 

NAIROBI-BASED  [ ADJ  ] 

NAIROBI  [ N LOC  ] 

NATIONAL  [ ADJ  ] 

NATURE  [ N ] . ; 

NAUTICAL  I ADJ  1 
NAVIGATIONAL  [ ADJ  ] 

NEAR  [ PREP  EMOD  J 
NEPAL  [ N LOC  NATION  ] 

NIGERIAN  [ ADJ  NATION  J 
NINE  [ NUM  ] 

NM  ( N SG  UNIT  ] . ; 

NMS  [ N PL  UNIT  ] 

NO  [ QUANT  ] . ; 

NORMAL  ( ADJ  ] 

NORTH  [ A DVB  DIR  ] [ ADJ  ] 

NORTHEAST  ( A DVB  DIR  ] [ ADJ  ] . ; 

NORTHERN  l ADJ  J 

NORTHWEST  [ A DVB  DIR  ] f ADJ  ] . ; 

NORTHWESTERN  [ ADJ  ] . ; 

NOTED  [ VB  TRANS  FASTF  OBSERVE  ] [ VB  TRANS  TENSED  OBSERVE  ] 

NOV  [ N TYME  MO  } 

NOVEMBER  I N TYME  MO  ] . ; 
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NYANJA  [ N LOC  3 . ; 

OCEAN  [ N LOC  ] . ; 

OCT  [ N TYME  MO  J . ; 

OCTOBER  [ N TYME  MO  ] 

OF  t PRF.F  3 

ON  [ PREP  EMOD  ] . ; 

ONE  [ NUM  ] . ; 

OPEN  [ ADJ  ] 

OPERATED  [ VB  PASTP  ACTVTY  3 [ VB  TENSED  ACTVTY  ) . ; 

OPERATING  l VB  PRESP  ACTVTY  ) 

OPERATIONS  [ N NOMZ  ] . ; 

ORBIT  t N LOC  ] 

OVER  [ PREP  EMOD  ] . ; 

PENETRATED  [ VB  TRAN'S  PASTP  PENETRATE  ] [ VB  TRANS  TENSED  PENETRATE  3 

PENETRATION  [ N NOMZ  ] 

PERFORMING  f.  VB  TRANS  PRESP  ACTVTY  3 
PERIOD  [ N TYME  ] 

PHANTOM  [ N NATO  A CRAFT  ] . ; 

PILOTS  I N PL  ] . ; 

PLESETSK  l N LOC  ] 

POSSIBLE  l ADJ  EVAL  ] 

POSSIBLY  [ ADVB  EVAL  ] 

PRECEDED  [ VB  TRANS  PASTP  BEFORE  3 l VB  TRANS  TENSED  BEFORE  ] 

PRECEDES  I VB  TRANS  TENSED  BEFORE  3 . ; 

PRESENTLY  [ ADVB  REE  TYME  J 
PRETORIA-BASED  £ ADJ  J 
PRETORIA  [ N LOC  ] 

PREVIOUS  [ ADJ  REF  TYME  ] . ; 

PREVIOUSLY  [ ADVB  REF  TYME  3 
PRIMARILY  [ ADVB  EVAL  3 
PROBABLE  [ ADJ  EVAL  3 
PROBABLY  I ADVB  EVAL  3 . ; 

PROCEEDING  [ VB  PRESP  DIR  FLIGHT  3 
RATS  [ N PL  3 . ; 

RECONNAISSANCE  [ N NOMZ  ] 

RECOVERABLE  [ ADJ  3 . ; 

RE-ENTER  l VB  TRANS  TENSED  RE  ENTER  3 
REGT  [ N SG  3 
REGIMENT  [ N SG  1 
REGIMENTS  [ N PL  ] 

REMAIN  [ COPULA  TENSED  ] 

REMAINED  I COPULA  TENSED  3 . ; 

REPORTING  l VB  TRANS  PRESP  3 
REPRESENTING  [ VB  TRANS  PRESP  3 

RETURNED  t VB  PASTP  RETURN  ] l VB  TENSED  RETURN  ] 

RETURNING  [ VB  PRESP  RETURN  ] 

RGT  [ N SG  1 . ; 

RIYADH  I N LOC  1 
ROUTINELY  I ADVB  ] 

S1234B  [ N SUBNUM  3 


SA554  [ N SUBNUM  ] 

SA622  [ N SUBNUM  ] 

SAFAF  [ N NATION  SERVICE  J . ; 

SAFLT  [ N NATION  SERVICE  ] 

SATELLITE  [ N SATELLITE  ] 

SAM-3  t N MISSILE  ] . ; 

SAME  [ ADJ  ] 

SC462  [ N SUBNUM  ] 

SCRAMBLED  [ ADJ  ] 

SEALED  [ ADJ  ] 

SEP  [ N TYME  MO  ] . ; 

SEPTEMBER  [ N TYME  MO  ] . ; 

SEYCHELLES  [ N LOC  ] . ; 

SIBERIA  [ N LOC  ] 

SIMULATED  [ ADJ  ] . ; 

SINCE  [ PREP  EMOD  TYME  ] . ; 

SIWAH  [ N LOC  ] 

SIX  [ NUM  ] . ; 

SKYHAWK  [ N NATO  ACRAFT  ] . ; 

SOFTLANDED  [ VB  TRANS  PASTP  LAND  J [ VB  TRANS  TENSED  LAND 
SOMALIA  I N LOC  NATION  J 
SOME  [ QUANT  ] . ; 

SOUTH  [ ADVB  DIR  ] [ ADJ  ] . ; 

SOUTHERN  [ ADJ  J 

SOUTHEAST  l ADVB  DIR  1 [ ADJ  } . ; 

SOUTHWEST  [ ADVB  DIR  ] [ ADJ  J 

SOUTWESTERN  [ ADJ  ] . ; 

SOVIET  [ ADJ  NATION  ] 

SOYUZ  [ N SATELLITE  J . ; 

SOYUZ-22  [ N SATELLITE  ] 

SOYUZ-28  [ N SATELLITE  ] 

SOYUZ-TYPE  ( ADJ  SATELLITE  ] 

SP26S  [ N SUBNUM  ] . ; 

SPACE  [ N LOC  ] . ; 

SPACECRAFT  [ N SCRAFT  ] 

SPACEFLIGHT  [ N ] 

SPORES  [ N ] 

SR-71  [ N TJPE  ACRAFT  ] 

SS-U  [ N MISSILE  ] . ; 

STAGING  t VB  PRESP  STAGE  ] 

STRATEGIC  [ ADJ  ] 

STRIKE  [ N NOMZ  ] 

STRIKES  [ N NOMZ  J 
SUAM  I N LOC  ] . ; 

SUBMARINE  IN].; 

SUBORDINATE  [ ADJ  ] 

SUCCESSFULLY  [ ADVB  EVAL  ] 

SUDAN  [ N LOC  ] . ; 

SUDANESE  [ ADJ  ] 

SUPPORT  [ N NOMZ  ] . ; 
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SURFACE-TO-AIR  [ ADJ  ] 

SURFACE  [ N LOC  ] . ; 

SURGUT  [ N LOC  ] 

SURVEILLANCE  [ N NOMZ  ] 

SYRIAN  [ ADJ  NATION  J 
TAIPEI  [ N LOC  ] 

TAIWAN  [ N LOC  NATION  ] 

TASK  [ N NOMZ  ] 

TEN  [ NUM  ] 

TESTING  [ VB  TRANS  PRESP  ] 

THAT  [ CONJ  ] [ RELPRO  ] [ ART  REF  ] . ; 

THE  [ ART  ] 

THESE  [ ART  REF  ] . ; 

THEY  [ PRO  ] . ; 

THEIR  [ ART  POSPRO  ] 

THIRD  [ ORD  ] . ; 

THIS  [ ART  REF  ] 

THOSE  I ART  REF  I . ; 

THREE  [ NUM  ] 

TIME  [ N TYME  ] 

TO  [ PREP  EMOD  ] 

TOBRUK  [ N LOC  ] . ; 

TODAY  [ N REF  TYME  J . ; 

TORORO  [ N LOC  ] 

TORTOISES  [ N I 
TRAINING  [ N ] 

TURNED  [ VB  PASTP  DIR  ] [ VB  TENSED  DIR  ] 

TURNING  [ VB  PRESP  DIR  ] 

TU-95  [ N TJPE  ACRAFT  ] 

TWO  [ NUM  ] 

TYRE  [ N LOC  ] 

TYURAT.AM  [ N LOC  ] 

U-43  t N TJPE  ACRAFT  ] 

U1009B  [ N SUBNUM  ] 

U1211B  [ N SUBNUM  ] 

U1232  [ N SUBNUM  ] 

U1324B  [ N SUBNUM  ] 

UABC  [ N J 
UAF  [ N ] 

UBBC  IN] 

UG254  [ N SUBNUM  ] 

UG836C  [ N SUBNUM  ] 

UGANDA  [ N LOC  NATION  ] . ; 

UGANDAN  [ ADJ  NATION  ] 

UNDERWAY  [ ADJ  FLIGHT  ] 

UNDETERMINED  [ ADJ  ] 

UNIDENTIFIED  I ADJ  ] 

UNITS  [ N PL  ] 

VARIOUS  [ ADJ  ] 

VICINITY  IN] 
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::  VIOLATED  [ VB  TRANS  PASTP  PENETRATE  ] 
::  WAS  [ BE  COPULA  TENSED  ] 

: : WEATHER  [ N ] . ; 

::  WERE  [ BE  COPULA  TENSED  ] 

::  WEST  [ ADVB  DIR  ] [ ADJ  ] . ; 

::  WESTERN  [ ADJ  ] 

::  WESTWARD  [ ADVB  DIR  ] 

::  WHICH  [ RELPRO  PRO  ] 

::  WOULD  [ MODAL  ] 

::  X [ N LOC  I 
::  XB442  [ N SUBNUM  ] 

::  XB2C2  [ N SUBNUM  ] 

::  ZEILA  [ N LOC  ] 

ENDLEX 


I VB  TRANS  TENSED  PENETRATE  ] 


•i 

i 

i 

: 
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Appendix  D - MATRES  II  Grammar 

(.  SGRAM. 4TH  — TEST  GRAMMAR  FOR  SENTENCES) 


GRAMMAR  DCL/ 

(.  DECLARATIONS) 
REGISTER  SUBJ 
REGISTER  OBJ 
REGISTER  VGRG 
REGISTER  PASSIVE 
REGISTER  VHRG 
REGISTER  DPRG 
REGISTER  DPF 
REGISTER  HNRG 
REGISTER  NPRG 
REGISTER  SNPF 
REGISTER  NRG 
REGISTER  PPRG 
REGISTER  PREPRG 
REGISTER  QPRG 
REGISTER  ARTRG 
REGISTER  N'UMRG 
REGISTER  VRG 
REGISTER  CPPG 
REGISTER  AGRG 
REGISTER  MONTH 
REGISTER  YEAR 
REGISTER  REL 
REGISTER  RELF 
REGISTER  RRF 
REGISTER  RR 
REGISTER  COMPL 
LIST  VMODS 
LIST  NUMLST 
LIST  PREMODS 
LIST  POSTMODS 
LIST  AUX 
LIST  ADVBLST 
LIST  PMODS 


LIST  DAY 

LIST  TP 

LIST  DCL 

5 

LABEL 

S 

4 

LABEL 

NP 

3 

LABEL 

DP 

2 

LABEL 

QP 

2 

LABEL 

NNODE 

3 

LABEL 

PP 

1 

LABEL 

P 

4 

LABEL 

VG 

2 

LABEL 

V 

3 LABEL  DATE 


(.  THE  DECLARATIVE  NET) 

: S DCL/  : 1 

: PSH  RELF  GETR  1 = ! I TO  S/SUBJ  * DCL  ADDLIST  =>  DCL/S  ,, 

: PSH  RRF  GETR  1 = ! ! 

VGRG  SENDR  PASSIVE  SENPR  VHRG  SENDR  VMODS  SENDL 
TO  S/VG  * DCL  ADDLIST  =>  DCL/S  , , 

:PSH  RELF  GETR  RRF  GETR  + 0 = !!  j 

TO  S/  * DCL  ADDLIST  =>  DCL/S  ,, 

: S DCL/S 

: CAT  [ SCONJ  ] ! ! * DCL  ADDLIST  =>  DCL/CONJ  ,, 

: JUMP  DCL/DCL  , , ' { 

:S  DCL/CONJ 

: PSH  * [ PRESP  ] ! ! TO  S/SUBJ  * DCL  ADDLIST  =>  DCL/S  ,, 

: PSH  TO  NP/  * DCL  ADDLIST  =>  DCL/S  ,, 

: S DCL/DCL 
: POP  DCL  , , 

9 9 


I 


3 


i 


(.  THE  SENTENCE  NET) 

: S S/ 

: PSH  TO  PP/  * VMODS  ADDLIST  =>  S/  , , 

: PSH  TO  D/  0 0 * PP  NODE  VMODS  ADDLIST  =>  S/  ,, 

: CAT  [ ADVB  TYME  ] !!  * VMODS  ADDLIST  =>  S/PP  ,, 

: JUMP  S/PP  ,, 

: S S/PP 

: PSH  TO  NP/  * SUBJ  SETR  =>  S/SUBJ  ,, 

> 9 

: S S/SUBJ 

: PSH  VMODS  SENDL  TO  VG/ 

* VGRG  SETR  PASSIVE  RETR  VHRG  RETR  VMODS  RETL  =>  S/VG  ,, 

9 9 

: S S/VG 

: PSH  PASSIVE  GETR  1 = • " BY"  AND  !!  TO  AG/ 

SUBJ  GETR  OBJ  SETR  * SUBJ  SETR  =>  S/OBJ  ,, 

: JUMP  5/OBJ  PASSIVE  GETR  1 = !! 

SUBJ  GETR  OBJ  SETR  0 SUBJ  SETR  ,, 

: PSH  PASSIVE  GETR  0 = VHRG  GETR  [ TRANS  ] AND  M 
TO  SN'P./  * OBJ  SETR  =>  S/OBJ  ,, 

: JUMP  S/OBJ  PASSIVE  GETR  0 = !'  ,, 

:S  S/OBJ 

: PSH  VMODS  SENDL  TO  VM/  VMODS  RETL  =>  S/S  ,, 
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: S S/S 

: POP  SUBJ  GETR  VGRG  GETR  OBJ  GETR  COMPL  GETR  VMODS  S NODE  ,, 

V t 


(.  THE  NOUN  PHRASE  SUBNET) 

: S NP/ 

: PSH  TO  SNF/  DPRG  RETR  PREMODS  RETL  HNRG  RETR  =>  NP/SNP  ,, 
I S NP/SNP 

: PSH  TO  POSTMODS/  POSTMODS  RETL  =>  NP/NP  ,, 

:S  NP/NP 

: POP  DPRG  GETR  PREMODS  HNRG  GETR  POSTMODS  NP  NODE  , , 

I » 


(.  THE  SIMPLE  NOUN  PHRASE  SUBNET) 

: S SNF/ 

: PSH  TO  DP/  « DPRG  SETR  PREMODS  RETL  1 SNPF  SETR  =>  SNP/DP  ,, 

: JUMP  SNP/DP  ,, 

I S SNP/DP 

: PSH  PREMODS  SENDL  TO  HN/  * HNRG  SETR  PREMODS  RETL  I SNPF  SETR  *■*  SNP/SNP 
: JUMP  SNP/SNP  ,, 

: S SNP/SNP 

: POP  SNPF  GETR  1 = ! ! 

DPRG  GETR  PREMODS  HNRG  GETR  POSTMODS  NP  NODE  , , 

* » 


(.  THE  DETERMINER  PHRASE  SUBNET) 

: S DP/ 

: PSH  TO  QP/  * QPRG  SETR  1 DPF  SETR  = ' DF/QF  , , 

: JUMP  DP/QP  , , 

:S  DP/QP 

: CAT  [ ART  ] !!  * ARTRG  SETR  1 DPF  SETR  =>  DF/ART  ,, 
: JUMP  DP/ART  , , 

:S  DP/ART 

: CAT  [ ADJ  ] ! ! * FREMODS  ADDLIST  =>  DP/ART  ,, 

: JUMP  DP/ PREMODS  ,, 

• • 

: S DP/PREMODS 

: PSH  TO  1/NUM  NMMLST  PFTL  1 DFF  SETR  DP  DP  ,, 

: JUMP  DP/DP  ,, 

:S  DP /DP 


: POP  DPF  GETR  1 = !! 

QPRG  GETR  ARTRG  GETR  NUMLST  DP  NODE  , , 

» i 


(.  THE  QUANTIFIER  PHRASE  SUBNET)  I 

: S QP/ 

: CAT  [ QUANT  ] !!  * 0 QP  NODE  QPRG  SETR  =>  QP/QP  ,, 

: PSH  TO  1/NUM  * NUMRG  SETR  =>  QP/NUM  ,, 

: S QP/NUM 

: WRD  " OF"  ! ! NUMRG  GETR  * QP  NODE  QPRG  SETR  =>  QP/QP  ,, 

j j 

: S QP/QP 

: POP  QPRG  GETR  ,, 

9 9 


(.  THE  NUMBER  SUBNET) 

: S 1/NUM 

:CAT  [ NUMMOD  ] !!  * NUMLST  ADDLIST  =>  1/NUM  ,, 

: CAT  [ ADVB  ] !!  * NUMLST  ADDLIST  =>  1/NUM  ,, 

: CAT  [ NUM  ] I!  * NUMLST  ADDLIST  =>  2/NUM  ,, 

: S 2/NUM 

: JUMP  1/NUM  * [ NUMMOD  ] * [ ADVB  ] * [ NUM  ] OR  OR  ! ! , , 
:WRD  ” AND”  ! ! * NUMLST  ADDLIST  =>  1/NUM  ,, 

: WRD  " TO"  !!  * NUMLST  ADDLIST  =>  1/NUM  ,, 

: POP  NUMLST  , , 

» 9 


(.  THE  HEAD  NOUN  SUBNET) 

: S HN/ 

: CAT  [ ADJ  ] !!  * PREMODS  ADDLIST  =>  HN/  ,, 

: CAT  [ PRESP  ] !!  * PREMODS  ADDLIST  =>  HN/  ,, 

: CAT  [ PASTP  ] I!  * PREMODS  ADDLIST  =>  HN/  ,, 

: PSH  * IN]  ! ! TO  N/  * HNRG  SETR  =>  HN/N  ,, 

: S HN/N 

: JUMP  HN/  * t ADJ  ] * [ PRESP  ) * [ PASTP  ] * IN]  OR  OR  OR  ! ! 

HNRG  GETR  PREMODS  ADDLIST  ,, 

: POP  HNRG  GETR  ,, 

i f 


(.  THE  NOUN  SUBNET) 

: S N/ 

: CAT  [ N ] ! ! * NRG  SETR  =>  N/N  ,, 

• • 

» » 


: S N/N 

: PSH  * " OF"  ! ! TO  PP/  * PPRG  SETR  =>  N/PP  ,, 
: JIMP  N/PP  ,, 

:S  N/PP 

: POP  NRG  GETR  PPRG  GETR  MODE  NODE  ,, 


(.  THE  PREP  PHRASE  SUBNET) 

: S PP/ 

:PSH  TO  1/NUM  * PMODS  A DDL  I ST  ='  PP/NUM  ,, 

: CAT  [ ADVB  ] * [ DIR  ] NOT  !!  * PMODS  ADDLIST  =>  PP/UNIT  ,, 
: JUMP  PP/UNIT  T, 

:S  PP/NUM 

: CAT  [ UNIT  ] !!  * PMODS  ADDLIST  =>  PP/UNIT  ,, 

: S PP/UNIT 

: CAT  [ PREP  ] !!  * PREPRG  SETR  =>  PP/PRE0  ,, 

: JUMP  PP/PREP  *-l  " ENROUTE"  !!  , , 

: S PP/PREP 

: PSH  PREPRG  GETR  [ TV ME  ] U TO  TP/  * OBJ  SETR  =>  PP/PP  ,, 

: PSH  TO  D/  * OBJ  SETR  =>  PP/PP  ,, 

: PSH  TO  SNP/  * OBJ  SETR  =>  PP/PP  lf 

:S  PP/PP 

: POP  PMODS  FREPRG  GETR  OBJ  GETR  PP  NODE  ,, 

5 t 


(.  THE  POST-HEAD  MODIFIER  SUBNET) 

: S POSTMODS/ 

: PSH  * [ RELPRO  ] I!  TO  R/  * POSTMODS  ADDLIST  =>  POSTMODS/F  ,, 

: PSH  « [ PRESF  } * [ PASTP  TRANS  ) OR  * l ADJ  ) OR 

* t ADVB  ] *+l  [ PRESP  ] *+l  f PASTP  TRANS  ] OR  [ ADJ  ] OR  AND  OR  !! 
TO  RR/  * POSTMODS  ADDLIST  =>  FOSTMODS/P  ,, 

: PSH  TO  PP/  * POSTMODS  ADDLIST  =>  POSTMODS/  ,, 

: JUMP  POSTMODS/P  , , 

: S POSTMODS/P 

: POP  POSTMODS  ,, 

) > 


(.  THE  RELATIVE  CLAUSE  SUBNET) 

: S R f 

:CAT  [ RELPRO  ] M =>  R/PRO  ,, 
i I 
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: S R/PRO 

: PSH  1 RELF  SETR  RELF  SEN DR  TO  DCL/ 
* REL  SETR  =>  R/R  ,, 

:S  R/R 

: POP  REL  GETR  ,, 


(.  THE  REDUCED  RELATIVE  CLAUSE  SUBNET) 

: S RR/ 

: PSH  TO  RVG/ 

* VGRG  SETR  PASSIVE  RETR  VHRG  RETR  VMODS  RETL 
= > RR/VG  , , 

:S  RR/VG 

: PSH  I RRF  SETR  RRF  SENDR  VGRG  SENDR  PASSIVE  SENDR  VHRG  SENDR  VMODS  SEN'DL 
TO  DCL/  * RR  SETR  =>  RR/RR  ,, 

! S RR/RR 

: POP  RR  GETR  , , 


(.  VERB  GROUP  SUBNET  FOR  REDUCED  RELATIVE  CLAUSES) 

: S RVG/ 

: CAT  [ ADVB  EVAL  ] !!  * ADVBLST  ADDLIST  =>  RVG/ADVB  ,, 

: CAT  [ ADVB  ] I!  * VMODS  ADDLIST  =>  RVG/ADVB  ,, 

: JUMP  RVG/ADVB  , , 

: S RVG/ADVB 

: CAT  [ PRESP  ] !!  * VHRG  SETR  =>  RVG/VH  ,, 

: CAT  [ ADJ  ] * [ PASTP  ] *+l  " BY”  AND  NOT  I! 

* VHRG  SETR  =>  RVG/VH  ,, 

: CAT  [ PASTP  ] !!  * VHRG  SETR  1 PASSIVE  SETR  =>  RVG/VH  ,, 
: S RVG/VH 

: POP  ADVBLST  AUX  0 VHRG  GETR  VG  NODE  , , 


(.  THE  VERB  GROUP  SUBNET) 

: S VG/ 

: PSH  VMODS  SENDL  TO  AU/ 

AUX  RETL  ADVBLST  RETL  VMODS  RETL  =>  VG/AUX  ,, 

:S  VG/AUX 

: CAT  [ COPULA  ) !!  * CPRG  SETR  =>  VG/COP  ,, 

: CAT  [ BE  ] ! ! =>  VG/BE  , , 

: CAT  [ VB  ] ! ! * VHRG  SETR  =>  VG/VH  ,, 


I 


: S VG/COP 

: CAT  [ ADv/B  EVAL  ] !!  * ADVBLST  ADDLIST  =>  VG/COP  ,, 

: CAT  [ ADVB  ] !!  * VMODS  ADDLIST  =>  VG/COP  ,, 

: CAT  [ *DJ  ] CPRG  GETR  [ BE  ] * [ PASTP  ] * + l " BY"  AND  AND  NOT  S! 
* VHRG  SETR  =>  VG/VH  , , 

: S VG/BE 

: CAT  [ ADVB  EVAL  ] !!  * ADVBLST  ADDLIST  =>  VG/BE  ,, 

: CAT  [ ADVB  ] ! ! VMODS  ADDLIST  =>  VG/BE  ,, 

: CAT  [ PASTP  ] !!  * VHRG  SETR  1 PASSIVE  SETR  =>  VG/VH  ,, 

: S VG/VH 

: POP  ADVBLST  AUX  CPRG  GETR  VHRG  GETR  VG  NODE  , , 

9 > 


(.  THE  AUXILIARY  SUBNET) 

: S AU/ 

: CAT  [ ADVB  EVAL  J !!  * ADVBLST  ADDLIST  =>  AU/  ,, 

: CAT  [ ADVB  ] !!  * VMODS  ADDLIST  =>  AU/  ,, 

:CAT  [ MODAL  ] !!  * AUX  ADDLIST  =>  AU/MDL  ,, 

: JUMP  AU/MDL  , , 

: S AU/MDL 

: CAT  [ ADVB  EVAL  ] !!  * ADVBLST  ADDLIST  =>  AU/MDL  ,, 

: CAT  [ ADVB  ] !!  * VMODS  ADDLIST  =>  AU/  ,, 

: CAT  [ HAVE  ] !!  * AUX  ADDLIST  =>  AU/HAVE  ,, 

: JUMP  AU/PASTP  , , 

: 5 AU/HAVE 

: CAT  [ ADVB  EVAL  ] !!  * ADVBLST  ADDLIST  =>  AU/HAVE  ,, 
: CAT  [ ADVB  ] !!  * VMODS  ADDLIST  =>  AU/HAVE  ,, 

: JUMP  AU/PASTP  * [ PASTP  ] !!  ,, 

:S  AU/PASTP 

: CAT  [ BE  ] M * AUX  ADDLIST  =>  AU/BE  ,, 

: JUMP  AU/AU  ,, 

: S AU/BE 

: CAT  [ ADVB  EVAL  ] !!  * ADVBLST  ADDLIST  =>  AU/BE  ,, 

: CAT  [ ADVB  ] !!  * VMODS  ADDLIST  =>  AU/BE  ,, 

: JUMP  AU/AU  * [ PRESP  ] !!  ,, 

:S  AU/AU 

: POP  AUX  , , 

» 9 


(.  THE  AGENT  NET) 
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: S AG/ 

: WRD  " BY"  !!  »>  AG/BY  ,, 

: S AG/ BY 

: PSH  TO  NP/  * AGRG  SETK  AG/AG  ,, 
: S AG/AG 

: POP  AGRG  GETR  , , 

9 » 


(.  THE  VMODS  SUBNET) 

: S VM/ 

: JUMP  VM/VM  * [ SCONJ  ] !!  ,, 

: PSH  *- 1 [ N 1 * l RELPRO  ] AND  ! I TO  R/  * VMODS  ADDL1ST  =>  VM/VM  , , 

: PSH  * [ PRESP  ] * [ PAST!’  TRANS  ] OR  * [ ADJ  ] OR 

* [ ADVB  ] [ PRESP  J * ♦ 1 [ PASTP  TRANS  ] OR  * ♦ 1 [ ADJ  ] OR  AND 

OR  * 1 [ N ] AND  ! ! 

TO  RR/  * VMODS  ADDI.IST  VM/VM  ,, 

: PSH  TO  FP/  * VMODS  ADDLIST  ='  VM/  ,, 

: CAT  l ADVB  DIR  ] !!  * VMODS  ADDLIST  ->  VM/  ,, 

: PSH  TO  D/  0 0 * PP  NODE  VMODS  ADDLIST  =>  VM/  ,, 

: JUMP  VM/VM  , , 

: S VM/VM 

: POP  VMODS  , , 

i t 


(.  THE  TIME  PHRASE  SUBNET) 

: S TP/ 

: WRD  " THE"  ! ! * TP  ADDLIST  > TF/THE  ,, 

: CAT  1 ADVB  EVAL  ] !!  * TP  ADDLIST  > TF/ADVB  ,, 
: JUMP  TP/ADVB  ,, 

: S TP/THE 

:CAT  [ ADJ  J ! ! * TP  ADDLIST  - ' TF/ADJ  ,, 

: JUMP  TP/ ADJ  ,, 

: S TP/ADJ 

: CAT  [N  TYME  ] !!  * TP  ADDLIST  ' TP/T  ,, 

: CAT  [ 4DIG  ] !!  * TP  ADDLIST  •=  > TP/T  ,, 

: S TP/T 

: CAT  [ TYME  UNIT  J !!  * TP  ADDLIST  > TP/TP  ,, 

: S TP/ADVB 

: CAT  IN  TYME  ] II  * TP  ADDLIST  =>  TP/ IT  ,, 

:CAT  l 4DIG  ] ! ! * TP  ADDLIST  TP/ IT  ,, 

f 9 
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: S TP/IT 

: WRD  " AND"  ! ! * TP  ADDLIST  =>  TP/CONJ  ,, 

: WRD  ” TO"  ! ! * TP  ADDLIST  =>  TP/CONJ  ,, 

: JUMP  TP/CONJ  , , 

: JUMP  TP/TP  , , 

: S TP/CONJ 

: CAT  [ N TYME  ] !!  * TP  ADDLIST  =>  TP/TP  ,, 
: CAT  [ 4 D I G ] !!  * TP  ADDLIST  =>  TP/TP  ,, 

9 9 

: S TP/TP 

: POP  TP  , , 


(.  THE  DATE  SUBNET) 

: S D/ 

: CAT  [ 1DIG  ] !!  * DAY  ADDLIST  =>  D/DAY  1 ,, 
: CAT  L 2DIG  J ! ! * DAY  ADDLIST  =>  D/DAYl  ,, 
:WBD  " THE"  !!  * DAY  ADDLIST  =>  D/ART  ,, 

: JUMP  D/ART  ,, 

: S D/DAYl 

: CAT  [ 1DIG  J !!  * DAY  ADDLIST  =>  D/LAY  ,, 

: CAT  [ 2DIG  ] !!  * DAY  ADDLIST  =>  D/DAY  ,, 

: JUMP  D/DAY  , , 

: S D/ART 

: CAT  [ ORD  ] !!  * DAY  ADDLIST  =>  D/DAY  ,, 

9 9 

: S D/DAY 

: CAT  [ MO  ] ! ! * MONTH  SETR  =>  D/MO  ,, 

9 9 

: S D/MO 

: CAT  [ 2DI G ] !!  * YEAR  SETR  =>  D/n  ,, 

CAT  [ 4DIG  J ! ! * YEAR  SETR  =>  D/D  ,, 

: JUMP  D/D  , , 

: S D/D 

: POP  DAY  MONTH  GETR  YEAR  GETR  DATE  NODE  , , 
ENDGRAMMAR 


Appendix  E - Test  Corpus 


>>  SIX  AUXILIARY  AVIATION  B-60  BUFF  HEAVY  BOMBERS  FROM  EABC  RGT  S1234B 
AT  MOGADISHU  CONDUCTED  FLIGHTS  OVER  THE  ARABIAN  SEA  BETWEEN  0220  AND 
0634Z  ON  21  FEBRUARY. 

>>  THE  PROBABLE  FOUR  EAFAF  B-60  AIRCRAFT  FROM  XB442  WHICH  CONDUCTED  OPERATIONS 
OVER  THE  NORTH  INDIAN  OCEAN  ARE  CURRENTLY  ENROUTE  HOMEBASE. 

>>  EIGHT  ETHIOPIAN  AUXILIARY  AVIATION  NORTHWEST  BOMBER  CORPS  B-60  BUFF 
HEAVY  BOMBERS  FROM  REGIMENT  E1651D  AT  MASSAWA  ARE  CURRENTLY  ACTIVE 
OVER  THE  GULF  OF  ADEN. 

>>  TWO  B-60  BUFF  A AIRCRAFT  FROM  THE  EAFAF  NATIONAL  GUARD  AUXILIARY 
SURVEILLANCE  AIR  REGIMENT  XB442  AT  ZEILA,  ARE  CURRENTLY  ACTIVE  OVER 
THE  NORTH  INDIAN  OCEAN  EAST  OF  KENYA. 

>>  EIGHT  UBBC  B-60  FROM  ENTEBBE,  STAGING  FROM  GULU,  CONDUCTED  FLIGHT 
OPERATIONS  ALONG  THE  SUDANESE  COAST. 

>>  AT  LEAST  TEN  UGANDAN  AUXILIARY  AVIATION  HEAVY  BOMBERS  ARE  CURRENTLY 
ENROUTE  TO  THE  RED  SEA. 

>>  TWO  INDIAN  OCEAN  FLEET  AIR  FORCE  B-60  BUFF  A AIRCRAFT  SUBORDINATE  TO 
NATIONAL  GUARDS  AUXILIARY  SURVEILLANCE  AIR  REGIMENT  AT  NAIROBI  ARE 
CURRENTLY  ACTIVE  OVER  TH  : NORTHERN  INDIAN  OCEAN  IN  AN  AREA  NORTHEAST  OF 
THE  SEYCHELLES. 

>>  TWO  EAFAF  B-60  BUFF  C AIRCRAFT  SUBORDINATE  TO  THE  NATIONAL  SURVEILLANCE 
AIR  REGIMENT  XB262  AT  NAIROBI  CONDUCTED  A PROBABLE  RECONNAISSANCE  OF  A 
SOUTH  AFRICAN  TASK  GROUP  SOUTHEAST  OF  MALAGASY. 

>>  TEN  UGANDAN  CONTINENTAL  AVIATION  UBBC  U1211B  ETBF  B-60'S  DEPLOYED  TO 
GULU. 

>>  THREE  BC254  B-61  BUFF  0 AIRCRAFT  CONDUCTED  AN  OPEN  OCEAN  MARITIME 
RECONNAISSANCE  NAVIGATIONAL  TRAINING  MISSION  TO  THE  GENERAL  AREA  SOUTHEAST 
OF  THE  LACCADIVES  ON  21/22  FEBRUARY. 

>>  THE  THREE  BC254  BUFF  D AIRCRAFT  WHICH  CONDUCTED  AN  OPEN  OCEAN  MARITIME 
RECONNAISSANCE  NAVIGATIONAL  TRAINING  MISSION  TO  THE  GENERAL  AREA 
SOUTHEAST  OF  THE  LACCADIVE  ISLANDS,  HAVE  RETURNED  TO  UGANDA  BY  0620Z. 

>>  TWO  B-60  BUFF  C AIRCRAFT  FROM  NATIONAL  SURVEILLANCE  AIR  REGT  UG254 
AT  GULU,  ARE  CURRENTLY  OPERATING  IN  THE  AREA  OF  THE  NYANJA  TASK  GROUP 
JUST  EAST  OF  THE  SEYCHELLES. 

>>  TWO  EAFAF  MOMBASA-BASED  KE843  B-60  BUFF  C AIRCRAFT  ARE  POSSIBLY 
CONDUCTING  COMMAND  AND  CONTROL  OPERATIONS  OVER  THE  ARABIAN  SEA  POSSIBLY 
IN  CONJUNCTION  WITH  A RETURNING  DELTA-CLASS  SUBMARINE. 


>>  THE  TWO  EAFAF  MOMBASA- BASED  KE843  B-60  BUFF  C AIRCRAFT  WHICH  WERE 
rOSSIBLY  CONDUCTING  COMMAND  AND  CONTROL  OPERATIONS  OVER  THE  SOUTHERN 
ARABIAN  SEA,  HAVE  RETURNED  TO  THE  AFRICAN  LANDMASS  BY  10302. 

>>  TWO  SOUTH  AFRICAN  SAFAF  CAPETOWN  BASED  SA554  B-60  BUFF  D ARE  PRESENTLY 
LOCATED  OVER  THE  SOUTH  ATLANTIC,  POSSIBLY  IN  REACTION  TO  TWO 
NIGERIAN  UNITS  LOCATED  EAST  OF  ST  HELENA. 

>>  THIS  FLIGHT  ACTIVITY  WAS  PRECEDED  BY  A WEATHER  RECONNAISSANCE  FLIGHT  BY 
ONE  PRETORIA- BASED  SP265  B-80  BEACON  TO  THE  CAPE  VERDE  ISLANDS. 

>>  THE  SIX  SOUTH  AFRICAN  FLEET  AIR  FORCE  SR- 71  ACFT  WHICH  CONDUCTED  ASlv 
ASSOCIATED  OPERATIONS  OVER  THE  ARABIAN  SEA  DURING  THE  PREVIOUS  PERIOD 
HAVE  RETURNED  TO  NORMAL  OPERATING  AREAS. 

>>  THE  MISSION  DESTINATION  OF  THESE  AIRCRAFT  IS  UNDETERMINED  AT  THIS  TIME. 

>>  AIRCRAFT  CONDUCTED  OPERATIONS  IN  AN  AREA  SOUTH  OF  MALAGASY. 

>>  AIRCRAFT  ARE  ACTIVE  OVER  THE  NORTHERN  INDIAN  OCEAN,  NORTH  OF  THE 
SEYCHELLE  ISLANDS. 

>>  AIRCRAFT  ARE  CURRENTLY  CONDUCTING  UNDETERMINED  OPERATIONS  IN  AN  AREA 
SOUTHEAST  OF  THE  MALDIVE  ISLANDS. 

>>  AIRCRAFT  CONDUCTED  FLIGHT  OPERATIONS  OVER  THE  ARABIAN  SEA  BETWEEN  1035 
AND  2219Z. 

>>  TWO  POSSIBLY  FOUR  SAFAF  CAPETOWN- BASED  SA622  BUFF  D AIRCRAFT,  STAGING 
FROM  PRETORIA,  ARE  CURRENTLY  OPERATING  OVER  THE  ARABIAN  SEA. 

>>  TWO  ARE  CURRENTLY  ENROUTE  RED  SEA. 

>>  TWO  MEDIUM  BOMBERS  FROM  REGIMENT  U1211B  AT  GULU  3247N3218E  CONDUCTED 
A RECONNAISSANCE  FLIGHT  OVER  THE  COMBAT  AREA  BETWEEN  1146  AND  1432Z. 

>>  ACTY  WAS  PRIMARILY  ASW  IN  NATURE. 

>>  TWO  NAIROBI  BASED  SR  7 1 FODDER  AIRCRAFT  ARE  CURRENTLY  ENROUTE  HOMEBASE 
AFTER  CONDUCTING  AN  INTELLIGENCE  COLLECTION  FLIGHT  ALONG  THE  SEYCHELLE 
ISLAND  CHAIN. 

>>  TWO  NAIROBI-BASED  SR  71  FODDER  AIRCRAFT  ARRIVED  IN  THE  VICINITY  OF  HOMEBASE 
AFTER  CONDUCTING  AN  INTELLIGENCE  COLLECTION  FLIGHT  ALONG  THE  SEYCHELLE 
ISLAND  CHAIN  BETWEEN  03  1 1-040 1Z. 

>>  AT  LEAST  46,  POSSIBLY  65,  SAFAF  B-60  BUFF  AIRCRAFT  REPRESENTING  THE 
THREE  STRATEGIC  REGIMENTS  IN  THE  SAFAF  ARE  PRESENTLY  LOCATED  OVER  THE 
ARABIAN  SEA  IN  A PROBABLE  SIMULATED  A1R-TO -SURFACE  EXERCISE  INVOLVING 
VARIOUS  SOUTH  AFRICAN  SURFACE  UMTS. 

>>  TWO  SAFAF  CAPETOWN  BASE!)  SC462  B 60  BUFF  C AIRCRAFT  ARE  CURRENTLY 
OPERATING  OVER  THE  ARABIAN  SEA. 
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>>  ALL  ACFT  PROBABLY  RETURN' ;D  TO  NORMAL  OPERATING  AREAS  BY  1 1 1 22. 


>>  TWO  SAFAF  CAPETOWN-  BASED  SC4&2  B-t>P  BUFF  C AIRCRAFT  OP  FF’.XT  > 1 1 
THE  ARABIAN  SEA  IN  PROBABLE  RECONNAISSANCE  SUPPORT  FOR  THE  STR > 
ACFT. 


>>  AT  LEAST  ONE  UGANDAN  AUXILIARY  AVIATION  B -hO  BUFF  WAS  '■  1 ’’  O’",:  i 

INDIAN  OCEAN  BETWEEN  0538-09202  ON  11  FEBRUARY. 


>>  TWO  SOUTH  AFRICAN  FLEET  AIR  FORCE  SAEAF  B-60  BUFF  AIRCRAFT 
PRESENTLY  DEPLOYED  TO  MAURITIUS,  WERE  ACTIVE  IN  POSSIBLE  ..OMVUNU  \.  V . 
EQUIPMENT  TESTING  FLIGHT. 


>>  FIGHT  UAF  GUl.U- BASED  UG836C  B 63  BEACON  AIRCRAFT,  POSSIBLY  , 

FROM  ENTEBBE,  CONDUCTED  A POSSIBLE  SMALL  SCALE  ADX  OVER  THE  BUJ’  .BUR. A 
COMPLEX  DURING  THE  EARLY  02002  HOUR. 

>>  THE  AIRCRAFT  PROBABLY  RETURNED  TO  NORMAL  OPERATING  hRI A BY  TUI  MID 
11002  HOUR. 


>>  TWO  UGANDAN  AUXILIARY  AVIATION  UBBC  B-03  BEACON  MEDIUM  BOMBERS  FROM 
REGIMENT  U1324E  AT  GULU  024*  3218E  DEPLOYED  TO  ENTEBBE  0ro3N3 
BETWEEN  0115  AND  03322. 

>>  CURRENTLY,  THREE  ADDITIONAL  U13246  B-63S  ARE  PROBABLY  ENROJiE 
ENTEBBE. 
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Appendix  F - Examples  of  System  Operation 


EXAMPLE  1 


*>>  TWO  UGANDAN  ACFT  FROM  REGIMENT  A313  AT  ENTEBBE  DEPLOYED  TO  GULU 
•AT  0200Z  ON  21  FEBRUARY. 

PARSE  OUTPUT: 

LIST  OF: 

I NODE:  IIS 
I I LIST  OF: 

I I I NODE:  21 PP 
I I I I NODE:  4 1 DATE 
I I I I I <<NIL>> 

| | I I | 392..  FEBRUARY 
I I I I I LIST  OF: 

I I I I I I 372..  21 
I I I I I END  LIST 

I I I I END  NODE 
I I I I 352..  ON 
| I | I LIST  OF: 

I I I I END  LIST 
I I I END  NODE 
I I I NODE:  21 PP 
I I I I LIST  OF: 

I I I I I 332..  0200Z 
I I I I END  LIST 
I I I I 312..  AT 
till  LIST  OF: 

I I I I END  LIST 
I I I END  NODE 
I I I NODE:  2 1 PP 
| I I I NODE:  2 1 NP 
I I I I I LIST  OP: 

I I I I I END  LIST 

| I I 11  NODE:  5 INNOD 
I II  I I I <<N1L>> 

| I I I ||  292.  .GULU 
| I I I I END  NODE 

I I I I I LIST  OF: 

I I I I I END  LIST 

I I I I I <<NIL>  > 

I I I I END  NODE 
I I I I 272.  . TO 
I I I I LIST  OF: 

I I I I END  LIST 
| I I END  NODE 
| | END  LIST 
I 1 <<NIL>> 

| I <<NIL>> 

I I NODt:  21 VG 
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I 232..  DEPLOYED 
I <<NIL>> 

I LIST  OF: 

I END  LIST 
I LIST  OF: 

I END  LIST 
END  NODE 
NODE:  2 1 NP 
I LIST  OF: 

I I NODE:  2 1 PP 
I I I NODE:  2 1 NP 
I I I I LIST  OF: 

I I I I END  LIST 
Mil  NODE:  5 INNOD 
I I I I I <<NIL>> 

I I I I I 212..  ENTEBBE 
I I I I END  NODE 
I I I I LIST  OF: 

I I I I END  LIST 

I I I I <<NIL>> 

II  I END  NODE 
I I t 192..  NT 
I I I LIST  OF: 

I I I END  LIST 
I I END  NODE 
I I NODE:  2 1 PP 
I I I NODE: 2 1 NP 
I I II  LIST  OF: 

I I I I END  LIST 
I I I I NODE:  5 INNOD 
I I I I I < <NIL> > 

I I I I I 172..A313 
I I II  END  NODE 
I I I I LIST  OF: 

I I I I I NODE:  5 INNOD 
I I I I II  <<NIL>> 


1 

I 

11  1 I 1 182..  REGIMENT 

1 

1 

1 1 1 1 END  NODE 

1 

1 

1 1 1 END  LIST 

1 

1 

1 1 1 <<NIL>> 

1 

1 

1 1 END  NODE 

1 

1 

1 1 1S2. . FROM 

1 

1 

1 1 LIST  OF: 

1 

1 

1 1 END  LIST 

1 

1 

1 END  NODE 

1 

1 

END  LIST 

1 

1 

NODE:  5 INNOD 

1 

1 

1 <<NIL>> 

1 

1 

1 132.  .ACFT 

1 

1 

END  NODE 

1 

1 

LIST  OF: 

1 

1 

1 112..  UGANDAN 

1 

1 

END  LIST 

1 

1 

NODE:  2| DP 

1 

1 

1 LIST  OF: 

1 

1 

1 1 92. . TWO 

1 

1 

1 END  LIST 

1 

1 

1 <<NIL>> 

1 

1 

1 <<NIL>> 

1 

1 

END  NODE 

1 

END  NODE 

END 

NODE 

END  LIST 


Event:  DEPLOY 
Object: 

. . . Equipment*  UGANDAN  ACFT 

...  National ity=  UGANDAN 

. . . Subordination=  FROM  REGIMENT  A3 13 

. . . Stagingbase=  AT  ENTEBBE 

. . . Number = TWO 

Destination=  TO  GULU 

Time=  AT  0200Z 

Date=  ON  21  FEBRUARY 

EVENT  RECORD  COMPLETE. 


EXAMPLE  2 


*>>  THE  ACFT  WERE  ENROUTE  TO  NAIROBI  BETWEEN  0200Z  AND  0400Z 

* ON  21  FEBRUARY  1965. 

PARSE  OUTFUT: 

LIST  OF: 

NODE:  IIS 
I LIST  OF: 

I I NODE:  2 1 PP 
I I I NODE:  4 1 DATE 
I I I I 350..  1965 
I I I I 330..  FEBRUARY 
I I I I LIST  OF: 

I I I I I 310..  21 
I I I I END  LIST 
I I I END  NODE 
I I I 290. . ON 
I I I LIST  OF: 

I I I END  LIST 
I I END  NODE 
I I NODE:  2 1 PP 
I I I LIST  OF: 

I I I I 270..  0400Z 
I I I I 250..  AND 
I I I I 230..  0200Z 
! i ! END  LIST 
I i I 210..  BETWEEN 
I I I LIST  OF: 

I I I END  LIST 
I I END  NODE 
I I NODE:  2 1 PP 
I I I NODE:  2 1 NP 
I I I I LIST  OF: 

I I I I END  LIST 
I I I I NODE:  5 INNOD 
I I I I I <<NIL>> 

I I I I I 190..  NAIROBI 
I I I I END  NODE 
I I I | LIST  OF: 

I I I I END  LIST 
I II  I <<N1L>> 

I I I END  NODE 
I I I 170..  TO 
I I I LIST  OF: 

I I I END  LIST 
I I END  NODE 
I END  LIST 
I <<NIL>> 

I < <NIL> > 

I NODE:  2 1 VG 
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I I I 150..  ENROUTE 
I I I 130..  WERE 
I I I LIST  OF: 

I I I END  LIST 
I I I LIST  OF: 

I I I END  LIST 
I I END  NODE 
I I NODE:  2 1 NP 
I I I LIST  OF: 

I I I END  LIST 
I I I NODE:  5 INNOD 
I I I I <<NIL>> 

I I I I 110..  AC FT 
I I I END  NODE 
I I I LIST  OF: 

I I I END  LIST 
I I I NODE:  2 1 DP 
I I I I LIST  OF: 

I I l I END  LIST 
I I I I 90..  THE 

I I I I «NIL>> 

II  I END  NODE 
I I END  NODE 

I END  NODE 
END  LIST 
Event:  ENROUTE 
Object: 

. . . Equipment^  ACFT 
. . . Number  = 

Destination=  TO  NAIROBI 
Time=  BETWEEN  0200Z  AND  0400Z 
Date=  ON  21  FEBRUARY  1965 
EVENT  RECORD  COMPLETE. 


F-5 


EXAMPLE  3 


*>>  THE  TWO  ACFT  WERE  ENROUTE  TO  NAIROBI  ON  RECONNAISSANCE. 
PARSE  OUTPUT: 

LIST  OF: 

I NODE:  IIS 
I I LIST  OF: 

I I | NODE:  2 1 PP 
I I I I NODE:  2 1 NP 
I I | I I LIST  OF: 

I I I I I END  LIST 

I I I I I NODE:  5 INNOD 

I I I I I I <<NIL>> 

I I I I I I 228..  RECONNAISSANCE 

I I I I I END  NODE 

I I I I I LIST  OF: 

I I I I I END  LIST 

I I I I I <<NIL> > 

I I I I END  NODE 
I I I I 208..  ON 
I I I I LIST  OF: 

I I I I END  LIST 
I I I END  NODE 
I I | NODE:  2IPP 
I I I I NODE:  2 1 NP 
I I | I I LIST  OF: 

I I I I I END  LIST 

I I I I I NODE:  5 INNOD 

I I I I I I <<NIL>  > 

I I II  II  188..  NAIROBI 
I I I I I END  NODE 

I I I I I LIST  OF: 

I I I I I END  LIST 

I I I I I <<NIL> > 

I I I I END  NODE 

II  I I 168..  TO 
II  I I LIST  OF: 

I I I I END  LIST 
I I I END  NODE 
I I END  LIST 
I I <<NIL>> 

I I <<NIL>> 

I I NODE:  2 |VG 
I I I 148..  ENROUTE 
I I | 128..  WERE 
I I I LIST  OF: 

I I I END  LIST 
I | I LIST  OF: 

I I I END  LIST 
I | END  NODE 
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NODE:  2INP 
I LIST  OF: 

I END  LIST 
I NODE:  5 INNOD 
I I < <NIL>  > 

I I 108..  ACFT 
I END  NODE 
I LIST  OF: 

END  LIST 
NODE:  2 I DP 
LIST  OF: 

I 88. . TWO 
END  LIST 
68..  THE 
<<NIL>> 

I END  NODE 
END  NODE 
END  NODE 
END  LIST 
Event:  ENROUTE 
Object: 

. . . Equipment=  ACFT 
. . . Number = TWO 
Misslon=  ON  RECONNAISSANCE 
Destination^  TO  NAIROBI 
EVENT  RECORD  COMPLETE. 


I 


I 
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Appendix  G - MATRES  II  Operations 


1.0  Introduction 

These  instructions  apply  only  to  the  OSI  PDP-11/45  running  under  the  standard  OSI 
RSX-11D  system.  On  that  system,  the  MATRES  II  files  are  stored  under  two  UFDs: 
[60,4]  contains  all  programs  and  data  except  for  the  template  file;  this  file  and  the  ERL 
compiler  are  stored  under  [60,5], 

2.0  Compiling  the  ERL  Templates 

The  source  for  the  templates  is  in  the  file  [60,5]TEMPLATE.ERL.  This  file,  like  ali  MATRES 
II  files,  may  be  modified  with  any  standard  editor.  The  compilation  procedure  is  as  fol- 
lows (assuming  that  you  are  logged  in  under  [60,5]): 

If  the  SPTBOL  program  has  not  been  installed: 

MCR> INS  [11,  50] SPTBOL/TASK=. . . SPT 
Then, 

MCR>  SERLCMPL 

The  command  file  will  do  the  rest.  If  any  syntax  errors  are  discovered,  the  offending 
clause(s)  will  be  printed  on  the  console.  Two  files  will  be  created:  TEMPLATE. INT,  the 
output  from  Pass  1,  and  TEMPLATE. 4TH,  the  final  output,  which  will  be  input  to  MATRES. 

3.0  Running  the  MATRES  System 

You  should  be  logged  in  under  [60,4],  The  procedure  is: 

If  the  FORTH  program  has  not  been  installed: 

MCR> INS  [60, 3] F0RTH/TASK  = . . . 4TH/ 1 NC=25500 
Then, 

MCR>4TH 

After  Forth  says  hello, 

•FORTH  LOAD 
•0MATRES 

After  "MATRES  READY!"  is  printed,  sentences  may  be  entered,  preceded  by  ">>  " and 
terminated  by  a period.  Sentences  may  span  multiple  lines,  breaking  at  word  boundaries 
Example: 

•>>  TWO  UGANDAN  ACFT  FROM  A313  AT  ENTEBBE  DEPLOYED  TO 
•GULU  AT  0200Z  ON  21  FEBRUARY. 

Event:  DEPLOY 
Object: 

. . . Equipment=  UGANDAN  ACFT 
...  Number = TWO 
...Subordinations  FROM  A313 
. . . Stagingbase=  AT  ENTEBBE 
Destination=  TO  GULU 
Time=  AT  0200Z 
Date=  ON  21  FEBRUARY 

There  are  various  debugging  switches  available  to  enable  printout  of  intermediate 
results.  To  set  a switch,  enter  "name  1SET";  to  reset  it,  enter  "name  OSET".  The  fol- 
lowing switches  exist  currently: 
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DEBUG  causes  a printout  of  the  lexical  units  as  they  are  found  by  lexical  processing, 
followed  by  a trace  of  the  parsing  process.  The  state  names  are  shown  in  Forth 
format,  as  a number  of  characters  followed  by  tho  first  four  characters  of  the 
name. 

PR1REE  causes  the  parse  tree  to  be  printed  out  after  a successful  parse.  The  ele- 
ments of  a node  and  members  of  a list  will  be  shown  in  reverse  order  from  that 
input  to  the  templates.  The  node  names  also  are  in  Forth  format. 

P-SW  causes  a trace  of  the  unification  process.  For  every  term  in  the  head  of  a 
clause  (and  every  term  in  a skeleton  in  the  head,  etc.),  the  corresponding  goal 
term  is  printed. 

PTRY  causes  a trace  of  clause  entries.  Clause  names  are  printed  in  Forth  format,  and 
consist  of  a C"  followed  by  a number.  This  will  be  the  number  of  the  clause  in 
the  original  source  file,  starting  from  zero.  Foi  instance,  "C27"  will  be  the  2Tth 
clause  from  the  top  one  in  the  TEMPLATE. ERL  file. 
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